Re: [Python-Dev] Trickery with moving urllib

[Brett C.]

On 10-May-08, at 20:43, [EMAIL PROTECTED] wrote:



   Brett> There is going to be an issue with the current proposal for
   Brett> keeping around urllib. Since the package is to be named  
the same

   Brett> thing as the module

Is this the only module morphing into a package of the same name?



Yes.

-Brett




Skip

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

Re: [Python-Dev] Copying cgi.parse_qs() to the urllib.parse module

[Brett C.]

-Brett [from his iPod touch]

On 10-May-08, at 20:49, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:


Works for me. The other thing I always use from cgi is escape() --
will that be available somewhere else too?



It can be. =)

-Brett



On Sat, May 10, 2008 at 8:30 PM, Brett Cannon <[EMAIL PROTECTED]>  
wrote:
I just realized that PEP 3108 was missing one proposal from the  
stdlib

SIG (originally proposed by Facundo Batista) of copying the
cgi.parse_qs() function over to the new urllib.parse module so that
people no longer need to import the cgi module just for that one
parsing function. Does anyone object if I update the PEP to include
that change?


--
--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] Trickery with moving urllib

[Brett C.]

-Brett [from his iPod touch]

On 10-May-08, at 23:46, "Alexandre Vassalotti" <[EMAIL PROTECTED]>  
wrote:



On Sat, May 10, 2008 at 11:43 PM,  <[EMAIL PROTECTED]> wrote:


  Brett> There is going to be an issue with the current proposal for
  Brett> keeping around urllib. Since the package is to be named  
the same

  Brett> thing as the module

Is this the only module morphing into a package of the same name?



No, it is not. The dbm package will have the same issue.



Ah nuts, forgot about that one.

-Brett




-- Alexandre

___
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] Trickery with moving urllib

[Brett C.]

-Brett [from his iPod touch]

On 10-May-08, at 23:58, "Alexandre Vassalotti" <[EMAIL PROTECTED]>  
wrote:


On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]>  
wrote:

I see three solutions for dealing with this.

1. Have stubs for the entire urllib API in urllib.__init__ that raise
a DeprecationWarning either specifying the new name or saying the
function/class is deprecated.

2. Rename urllib to urllib.fetch or urllib.old_request to get people
to move over to urllib.request (aka urllib2) at some point.



I am probably missing something, because I don't see how this solution
would solve the problem. The warning in urllib.__init__ will still be
issued when people will import urllib.fetch (or urllib.fetch).



No, you are probably right. My brain is mush at the moment.

-brett




-- Alexandre

___
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] Trickery with moving urllib

[Brett C.]

-Brett [from his iPod touch]

On 11-May-08, at 0:04, Fred Drake <[EMAIL PROTECTED]> wrote:

On Sat, May 10, 2008 at 11:38 PM, Brett Cannon <[EMAIL PROTECTED]>  
wrote:

I see three solutions for dealing with this.

1. Have stubs for the entire urllib API in urllib.__init__ that raise
a DeprecationWarning either specifying the new name or saying the
function/class is deprecated.


On May 11, 2008, at 2:58 AM, Alexandre Vassalotti wrote:
I am probably missing something, because I don't see how this  
solution

would solve the problem. The warning in urllib.__init__ will still be
issued when people will import urllib.fetch (or urllib.fetch).



Were the warnings issued on import, yes, but I think Brett's  
suggestion was really about issuing warnings when the stub functions  
were called.  For classes, I guess this could be handled using the  
__init__ methods, but I'm not sure I like that, or that it will be  
easy to get exactly the right behavior in all cases.




Another option is to not worry about warnings in this specific case  
and fully rely on 2to3. The issue of urllib and splitting its API  
across 2 files stands, though. That could be solved with a urllib._old  
module for now that eventually gets a deprecation warning.







 -Fred

--
Fred Drake   





___
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] String literal concatenation & docstrings

[Brett C.]

Guido van Rossum wrote:
Right.  Over-clarification results in docs that read like the
instructions for the holy hand grenade ;-)
Well said.

Except that now I can't find the adjacent string literals in the
grammar any more!
I'm looking al http://www.python.org/dev/doc/devel/ref/grammar.txt
The path goes from primary to atom to literal to stringliteral (and
from there on into lexical detail) and nowhere does the grammar show
that multiple string literals are allowed. Adding a single + after
stringliteral in the expansion for literal would fix this
[SNIP]
But if you look at Grammar/Grammar you will notice that atom goes to STRING+ 
which should cover this.  Is that grammar.txt file generated from 
Grammar/Grammar or is it done by hand?

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] TRUNK UNFROZEN; release24-maint branch has been cut

[Brett C.]

Anthony Baxter wrote:
I've cut the release24-maint branch, and updated the Include/patchlevel.h
on trunk and branch (trunk is now 2.5a0, branch is 2.4+)
The trunk and the branch are now both unfrozen and suitable for checkins.
The feature freeze on the trunk is lifted. Remember - if you're checking 
bugfixes into the trunk, either backport them to the branch, or else mark 
the commit message with 'bugfix candidate' or 'backport candidate' or the
like.

Next up will be a 2.3.5 release. I'm going to be travelling for a large chunk
of December (at very short notice) so it's likely that this will happen at the
start of January.
OK, I will send out an email to python-list and python-announce mentioning this 
to the community and that if they have fixes they need to go into 2.3.5 they 
need to get it in ASAP so there is enough time to consider them (with no 
guarantee they will get in) at the end of the week if no one objects.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

I noticed that Makefile.pre.in uses the value from the environment variable 
LDFLAGS but not CPPFLAGS.  Any reason for this?  ``./configure -h`` lists both 
(and some other environment variables which are not really used either) so it 
seems a little misleading to have those listed but to not utilize them.

The reason I ask is I plan on having setup.py add the directories specified in 
both of these environment variables for compiling the extension modules.  It 
would be nice to be able to use the same values as used by the Makefile to 
build the core, but I can if I must just get the values directly from the 
environment variables themselves.

This should allow for the removal of the direct support for Fink and 
DarwinPorts.  It should also remove any hand-editing needed to get setup.py to 
pick up any non-standard library and header locations.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Brett C.]

Martin v. Löwis wrote:
Anthony Baxter wrote:
The library docs for, e.g. xmllib already say deprecated at the top - 
maybe
it should be larger?

I think it would be better to *remove* the xmllib documentation.
Existing code which needs the module will continue to work even
without documentation, and new code is unlikely to be written for
a module that has no documentation, and where importing the module
gives a DeprecationWarning.
I like this solution.  And if anyone cares about having good docs still for a 
deprecated module they can just read the docstrings.  We don't get new people 
using it but others don't have to change their code.

And as for the mention of dropping PEP 4, I agree with the running consensus 
that it isn't needed thanks to the warning module.  Do we need to have a more 
formal vote to drop PEP 4, or should one the PEP maintainers just delete it?

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment 
variable LDFLAGS but not CPPFLAGS.  Any reason for this? 

How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I realize that much.  But if you look in configure.in it seems to use the 
previous value of LDFLAGS every time it is redefined as a base and thus gets 
its initial value from the environment variable the first time it is tweaked.

Not a big deal, though.  I will just use the environment variables in setup.py .
-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment 
variable LDFLAGS but not CPPFLAGS.  Any reason for this? 

How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no mention of 
CPPFLAGS anywhere.  And yet if I modify the definition of CPPFLAGS in 
Makefile.pre.in to ``-I. -I./Include @[EMAIL PROTECTED] it ends up containing the 
value I have for the environment variable at the end of it.  I think the '@@' 
syntax uses a value from configure.in if it is defined else it defaults to the 
value the shell has.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Ptyon 2.3.5 probably coming in January; get your bugs/patches reported!

[Brett C.]

Anthony Baxter, our ever-diligent release manager, mentioned this past week 
that Python 2.3.5 will most likely come to fruition some time in January (this 
is not guaranteed date).  This means that in order to have enough time to 
proper evaluate new patches and bugs they must be reported **now**!  A one 
month lead time is necessary to properly look at, test, and commit patches, let 
alone coming up with solutions to any reported bugs.

Please realize, though, that reporting a bug or submitting a patch now does not 
guarantee that it will committed in time!  The free time of the development 
team is limited.  If you want to help a bug or patch along to make it easier to 
be evaluated and thus raise its chances of being dealt with please see the 
"Helping Out" section of the 'Intro to Development' essay at 
http://www.python.org/dev/dev_intro.html .

As always, both bugs and patches should be reported to Python's SourceForge 
tracker at http://sourceforge.net/bugs/?group_id=5470 and 
http://sourceforge.net/patch/?group_id=5470, respectively.

-Brett Cannon
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no 
mention of CPPFLAGS anywhere.

Right. That's what I meant when I said "has nothing to compute", so
it does not even mention CPPFLAGS.
And yet if I modify the definition of CPPFLAGS in Makefile.pre.in to 
``-I. -I./Include @[EMAIL PROTECTED] it ends up containing the value I have 
for the environment variable at the end of it.  I think the '@@' 
syntax uses a value from configure.in if it is defined else it 
defaults to the value the shell has.

Indeed, that seems to be the case. However, absence of @CPPFLAGS@
means that Makefile.pre will just use the static value from
Makefile.pre.in.
That's basically the functionality I need, so I am going with it.
Whether or not adding @CPPFLAGS@ to the end is the right thing,
I don't know.
Well, we will soon find out.  =)  My checkin made this change and everything 
seems fine.  If it doesn't work out I will have to create another environment 
variable to store the value.

Michael's desire of getting the Fink and DarwinPorts special casing in setup.py 
is now solved; setup.py now uses the directories specified in LDFLAGS and 
CPPFLAGS for compiling the extension modules.  I didn't bother with CFLAGS or 
CC since the former is mostly handled by BASECFLAGS it seems and the latter is 
specified by arguments to configure.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
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 338: Executing modules inside packages with '-m'

[Brett C.]

Nick Coghlan wrote:
Python 2.4's -m command line switch only works for modules directly on 
sys.path.
Trying to use it with modules inside packages will fail with a "Module not
found" error. This PEP aims to fix that for Python 2.5.

Previously, posting of a draft version of the PEP to python-dev and 
python-list
didn't actually generate any responses. I'm not sure if that's an 
indication
that people don't see the restriction to top-level modules as a problem 
(and
hence think the PEP is unecessary), or think the extension to handle 
packages is
obvious (and hence see no need to comment).

For c.l.p, it could just be a sign that Python 2.4 hasn't been out long 
enough for anyone to care what I'm yabbering on about :)

Anyway, all comments are appreciated (even a simple "Sounds good to me").
Sounds good to me. =)
+1
-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-dev Summary for 2004-10-16 through 2004-10-31 [draft]

[Brett C.]

Winter Break is upon me which means I have time to catch up on the Summaries. 
I will definitely be caught up by the end of the month.

As for this summary, I will send this out around Wednesday.  As always 
corrections are appreciated.  If you feel one of the skipped threads deserves 
coverage please feel free to write up a summary and I will edit it and include it.

--
=
Summary Announcements
=
`Python 2.4`_ final is now out!
As I mentioned in the last summary my school schedule this past quarter has 
been insane.  But now I am on Winter Break and will hopefully be able to catch 
up on my Summary backlog.

.. _Python 2.4: http://www.python.org/2.4/
=
Summaries
=

Specifying main functions and calling packages with '-m'

In my opinion, the new '-m' command line option in Python 2.4 is really handy. 
 But wouldn't it be even handier if you could execute modules in a package? 
That exact question came up.  The reason this kind of thing didn't just go 
directly into 2.4 was that the semantics are not as obvious nor is it as 
simple.  A PEP is on the way, though.  Until then, you can use Nick Coghlan's 
recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/307772.

This also brought up the discussion of being able to specify a 'main' function 
to take the place of the good old ``if __name__ == "__main__"`` idiom.  Some 
liked the idea of allowing one to define a function named 'main', others 
'__main__'.  But the discussion never went any farther.  This will require a 
PEP to ever even be seriously considered.

Contributing threads:
  - `python-dev Summary for 2004-09-16 through 2004-09-30 [draft] <>`__
  - `Magic main functions <>`__
  - `Supporting packages on the command line <>`__

ConfigParser shootout begins

As mentioned in the `last summary`_, a desire for a replacement for 
ConfigParser has come into being.  It seems the ideas are being hashed out in 
the wiki at http://www.python.org/moin/ConfigParserShootout .

Contributing threads:
  - `ConfigParser shootout, preliminary entry <>`__
  - `What are the goals for ConfigParser 3000? <>`__

Making pymalloc friendlier to long running processes

Pymalloc, when a small chunk of memory is requested that is less than 256 
bytes, fetches the memory from a pool of previously used memory that is now 
available.  While this speeds up memory allocation since it does not directly 
involve calling the OS to free up the memory, it does cause issues for long 
running processes that have at some point requested a large portion of memory. 
 The example in the OP for this whole topic was an app that needs 1GB for 
about five minutes, but the amount of allocated memory stays at 1 GB since 
pymalloc does not free it to the OS.

This was brought up back in June and is summarized at 
http://www.python.org/dev/summary/2004-06-01_2004-06-15.html#id17 .

No code has been checked in at the moment to change the behavior partially 
thanks to the difficulty of the problem.

Contributing threads:
  - `Changing pymalloc behaviour for long running processes <>`__
  - `Re: Python-Dev Digest, Vol 15, Issue 46 <>`__

How to get a patch looked at

Often times people have a specific patch that they want reviewed/applied to 
solve a specific problem they are having.  Unfortunately the Python developers 
have limited time; we just can't get to every patch there in a timely fashion. 
 This can be a problem who *really* need to get a patch in.

Enter Martin v. LÃwis and his deal to review a specific patch:
1. Review 10 other patches on SF
2. Send an email to python-dev listing the 10 patches that you reviewed and the 
one patch you want to be reviewed
3. Your specific patch gets reviewed by Martin

You can see the exact details of Martin's requirements at 
http://mail.python.org/pipermail/python-dev/2004-October/049495.html and can 
also read http://www.python.org/dev/dev_intro.html for ideas on what to do for 
reviewing.

Contributing threads:
  - `Patches <>`__
--
Discussion of including pysqlite in the stdlib
--
The idea of including pysqlite_ in the stdlib came up once again (not this is 
the wrapper for SQLite_ and not SQLite itself).  The arguments for including 
the module were the SQLite is most likely used more than Sleepycat and thus 
deserved a place in the stdlib if bsddb did.  It also goes along with Python's 
idea of "batteries included".

Arguments against started with the idea of sanctioning pysqlite over other 
SQLite wrappers did not seem proper.  People also thou

Re: [Python-Dev] httplib timeout patch

[Brett C.]

ZhangYueåå wrote:
Hi,
Here is a patch for httplib. I added a timeout value for 
httplib.HTTPConnection, please check.

Thanks for the patch, but this is the wrong place for it.  Please create a new 
patch item on SourceForge at http://sourceforge.net/patch/?group_id=5470 .

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: Python in education

[Brett C.]

Terry Reedy wrote:
"Randy Chung" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
[SNIP]
I'm  interested in using actual bugs in Python as exercises

Please consider including review of existing patches.  Besides being 
useful, it will also teach students how to submit good patches of their 
own.

To go along with this suggestion, see http://www.python.org/dev/dev_intro.html 
for the basic overview of what a review tends to consist of.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] python-dev Summary for 2004-11-01 through 2004-11-15 [draft]

[Brett C.]

Now I am only a month behind.
Won't send this out any earlier than Monday night, but probably won't be until 
Tuesday.


=
Summary Announcements
=
I am hoping to be caught up with my summary backlog by the end of the month. 
Hear is to hoping.

=
Summaries
=

2.4 released

`Python 2.4`_ has been released!  Read the `What's New`_ for 2.4 to see what 
the major changes are since 2.3 .

.. _Python 2.4: http://www.python.org/2.4/
.. _What's New: http://www.python.org/doc/2.4/whatsnew/whatsnew24.html
Contributed threads:
  - `TRUNK FROZEN for 2.4b2 release from UTC 3rd November (tomorrrow) <>`__
  - `RELEASED Python 2.4, beta 2 <>`__
  - `TRUNK UNFROZEN <>`__
-
Code coverage of the regression tests
-
Walter DÃrwald has a code coverage tool that runs once a month on Python's 
regression test at http://coverage.livinglogic.de/ .  There was some issue with 
the 'trace' module having partially broken in 2.4 .  The coverage was then run 
using ``Lib/test/regrtest.py -T`` to get more accurate numbers.

Contributing threads:
  - `Code coverage tool updated <>`__

Garbage collecting weakref callbacks

Tim Peters discovered that in 2.4 if a weakref's callback is still reachable 
but the referent and weakref itself are unreachable (Tim's example had an 
instance that contained a weakref to itself) that the callback is not called 
during garbage collection.  This seemed inconsistent since if the weakref in 
Tim's example was replaced with an instance that contained a __del__ method 
that the method would have been called.

Tim would like to clean this up so as to be able to ditch __del__ methods in 
Python 3000.  The idea is that one would register a weakref with a callback for 
an object in itself that would be called when it is garbage collected.  This 
would also negate the need for gc.garbage .

Contributing threads:
  - `weakref gc semantics <>`__
  - `patch-finalizer vs Zope3 <>`__
-
PEP Watch
-
`PEP 336`_ introduces the idea of having None be a callable object.  The result 
that calling None would return None itself.

.. _PEP 336: http://www.python.org/peps/pep-0336.html
Contributing threads:
  - `PEP 336, "Make None Callable", by Andrew McClelland <>`__
--
Discussion of including pysqlite in the stdlib
--
The idea of including pysqlite_ in the stdlib came up once again (not this is 
the wrapper for SQLite_ and not SQLite itself).  The arguments for including 
the module were the SQLite is most likely used more than Sleepycat and thus 
deserved a place in the stdlib if bsddb did.  It also goes along with Python's 
idea of "batteries included".

Arguments against started with the idea of sanctioning pysqlite over other 
SQLite wrappers did not seem proper.  People also thought that including bsddb 
might not be correct anymore and thus should not be used as a basis for 
including pysqlite.

This all then led into a discussion about package management and how to 
simplify extending what can be installed at compile-time.  The idea of pushing 
PyPI_ came up as well as revising `PEP 206`_.

.. _pysqlite: http://pysqlite.org/
.. _SQLite: http://www.sqlite.org/
.. _PyPI: http://www.python.org/pypi
.. _PEP 206: http://www.python.org/peps/pep-0206.html
Contributing threads:
  - `SQLite module for Python 2.5 <>`__

2.3 maintenance coming to an end

With Python 2.4 out, maintaining 2.3 is no longer a priority. Anthony Baxter, 
our beloved release manager, has said that 2.3.5 will be most likely coming out 
in January.  After that, though, don't count on another 2.3 release since 2.4 
will take its place as the version to maintain.

All of this came about by the fact that Facundo Batista asked if closing 2.1 
bugs was okay.  As long as they have been fixed in the earliest version being 
maintained, closing them is fine.  This goes for 2.2 as well.  And as soon as 
2.3.5 is out the door will most likely apply to 2.3 bugs.

Contributing threads:
  - `Policy about old Python versions <>`__
-
Sync/async servers in the stdlib and whether they should be there
-
There are multiple servers in the core for handling communications in both a 
synchronous and asynchronous manner.  The idea came up of developing an API 
that all servers could follow in the core.  While the discussion went back and 
forth with multiple mentions of PEAK, Twisted, and greenlets_, in the end the 
trend of the discussion suggested doing this well would be very difficult and 
not worth the effort.  asyncore and a

Re: [Python-Dev] RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 2.300.8.11

[Brett C.]

Andrew MacIntyre wrote:
I don't see any possible way for those checkins to affect any platform
other than OS/2.
2 of the files are platform specific files (PC/os2emx/getpath.c,
PC/os2vacpp/getpath.c), and the checkin to Modules/posixmodule.c is
contained within a platform specific #if/#endif:
Perhaps, but if you look at line 3299 you will notice that a comment is started 
but not closed off before the next comment on line 3304.  How is that comment 
supposed to be closed off?

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Patches: 1 for the price of 10.

[Brett C.]

Martin v. Löwis wrote:
Jeremy Hylton wrote:
I got started on these this morning, will likely finish them tomorrow.
 It would be perverse to apply your patch last, wouldn't it?

It turns out that Titus' patch might be more involved than he thought
it would be.
In any case, the review itself is a highly appreciated contribution.
In the hope that this progress can trigger more contributions like this,
I'll happily reduce the requirements to 5 reviews.
And to help this along I am willing to officially toss my hat into the fray by 
being another person who will review a patch if someone does 5 reviews (sans 
anything that doesn't work on OS X, which leaves out Tkinter).

-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] proto-pep: How to change Python's bytecode

[Brett C.]

After implementing over 10 new opcodes for my thesis I figured I should write 
down the basic steps in an info PEP so that there is enough guidelines with 
this PEP and PEP 306 to cover the bases on changes to the language itself.

To go along with this I also plan to write some benchmarks for individual 
opcodes that could possibly lead to a testing suite for the opcodes themselves 
(will probably do this piece-meal and put it up on SF initially since there are 
a lot of opcodes).

Anyway, let me know if I seem to be missing anything or have something to add. 
 After a reasonable time of non-response to this I will request a PEP number 
(assuming people don't think this PEP is stupid).

--
PEP: XXX
Title: How to change Python's bytecode
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Brett Cannoon <[EMAIL PROTECTED]>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: XX-XXX-
Post-History: XX-XXX-
Abstract

Python source code is compiled down to something called bytecode.  This
bytecode (which can be viewed as sequences of opcodes) defines what Python is
capable of.  As such, knowing how to add, remove, or change the bytecode is
important to do properly when changing the abilities of the Python language.
Rationale
=
While changing Python's bytecode is not a frequent occurence, it still happens.
Having the required steps documented in a single location should make
experimentation with the bytecode easier since it is not necessarily obvious
what the steps are to change the bytecode.
This PEP, paired with PEP 306 [#PEP-306]_, should provide enough basic
guidelines for handling any changes performed to the Python language itself in
terms of syntactic changes that introduce new semantics.
Checklist
=
This is a rough checklist of what files need to change and how they are
involved with the bytecode.  All paths are given from the viewpoint of
``/cvsroot/python/dist/src`` from CVS).  This list should not be considered
exhaustive nor to cover all possible situations.
- ``Include/opcode.h``
This include file lists all known opcodes and associates each opcode
name with
a unique number.  When adding a new opcode it is important to take note
of the ``HAVE_ARGUMENT`` value.  This ``#define``'s value specifies the
value at which all opcodes that have a value greater than
``HAVE_ARGUMENT`` are expected to take an argument to the opcode.
- ``Lib/opcode.py``
Lists all of the opcodes and their associated value.  Used by the dis
module [#dis]_ to map bytecode values to their names.
- ``Python/ceval.c``
Contains the main interpreter loop.  Code to handle the evalution of an
opcode here.
- ``Python/compile.c``
To make sure an opcode is actually used, this file must be altered.
The emitting of all bytecode occurs here.
- ``Lib/compiler/pyassem.py``, ``Lib/compiler/pycodegen.py``
The 'compiler' package [#compiler]_ needs to be altered to also reflect
any changes to the bytecode.
- ``Doc/lib/libdis.tex``
The documentation [#dis-docs] for the dis module contains a complete
list of all the opcodes.
- ``Python/import.c``
Defines the magic word (named ``MAGIC``) used in .pyc files to detect if
the bytecode used matches the one used by the version of Python running.
This number needs to be changed to make sure that the running
interpreter does not try to execute bytecode that it does not know
about.
Suggestions for bytecode development

A few things can be done to make sure that development goes smoothly when
experimenting with Python's bytecode.  One is to delete all .py(c|o|w) files
after each semantic change to Python/compile.c .  That way all files will use
any bytecode changes.
Make sure to run the entire testing suite [#test-suite]_.  Since the
``regrtest.py`` driver recompiles all source code before a test is run it acts
a good test to make sure that no existing semantics are broken.
Running parrotbench [#parrotbench]_ is also a good way to make sure existing
semantics are not broken; this benchmark is practically a compliance test.
References
==
.. [#PEP-306] PEP 306, How to Change Python's Grammar, Hudson
   (http://www.python.org/peps/pep-0306.html)
.. [#dis] XXX
.. [#test-suite] XXX
.. [#parrotbench] XXX
.. [#dis-docs] XXX
Copyright
=
This document has been placed in the public domain.

..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   End:
___
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] Re: proto-pep: How to change Python's bytecode

[Brett C.]

Scott David Daniels wrote:
Brett C. wrote:
A few things can be done to make sure that development goes smoothly when
experimenting with Python's bytecode.  One is to delete all .py(c|o|w) 
Don't you mean ".pyc or .pyo (remember such files in zips as well)"
.pyw is normal python source.
Yeah, my bad.  Been a while since I have written a .pyw file.
-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] Re: proto-pep: How to change Python's bytecode

[Brett C.]

Terry Reedy wrote:
"Brett C." <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

At to the title, bytecodes are a property of the CPython implementation, 
not of Python itself.  Since I think the distinction is quite important to 
maintain, I would insert the missing 'C' and everywhere else as 
appropriate.

Then the same could be said for PEP 306.  But I don't mind changing the 
title.

After implementing over 10 new opcodes for my thesis I figured I should 
write down the basic steps in an info PEP so that there is enough 
guidelines with this PEP and PEP 306 to cover the bases on changes to the 
language itself.

Over the last several years, various people have reported experimenting 
with CPython's bytecodes.  I wonder if it would be helpful to have a 
respository of the results, in one place, for new experimenters and curious 
people to peruse.

Wouldn't hurt.  Adding that section would not be bad, but I don't have the 
inclination to hunt them down.  What do others think about having this section?

-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] Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209

[Brett C.]

Jack Jansen wrote:
On 18-dec-04, at 21:48, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21493
Modified Files:
setup.py
Log Message:
Switch from getting LDFLAGS and CPPFLAGS from the environment to the 
Makefile.
This is to avoid a problem that inconsistently comes up where the 
environment
variable is unset while the Makefile clearly has the values set and 
are used
during ``make``.

Brett,
I'm building MacPython binary distributions with an LDFLAGS configure 
option, as in
$PYTHONSRC/configure -C --enable-framework LDFLAGS=-Wl,-x

This has suddenly started failing with a very mysterious error message. 
When the
make tries to build the extension modules I get
running build
running build_ext
usage: setup.py [options]
setup.py: error: no such option: -W

Could this somehow be caused by your fix?
Yep, it's my doing.  I bet optparse is raising an error since it doesn't have 
options for -W1 or -x registered with the parser.  Anyone off the top of their 
head know how to cause optparse to just skip over options it doesn't know about?

I am on vacation at the moment so I will deal with this when I get back this 
weekend.

-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] Zipfile needs?

[Brett C.]

Scott David Daniels wrote:
I'm hoping to add BZIP2 compression to zipfile for 2.5.  My primary
motivation is that Project Gutenberg seems to be starting to use BZIP2
compression for some of its zips.  What other wish list things do
people around here have for zipfile?  I thought I'd collect input here
and make a PEP.
Encryption/decryption support.  Will most likely require a C extension since 
the algorithm relies on ints (or longs, don't remember) wrapping around when 
the value becomes too large.

-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] Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209

[Brett C.]

Brett C. wrote:
Jack Jansen wrote:
On 18-dec-04, at 21:48, [EMAIL PROTECTED] wrote:
Update of /cvsroot/python/python/dist/src
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21493
Modified Files:
setup.py
Log Message:
Switch from getting LDFLAGS and CPPFLAGS from the environment to the 
Makefile.
This is to avoid a problem that inconsistently comes up where the 
environment
variable is unset while the Makefile clearly has the values set and 
are used
during ``make``.

Brett,
I'm building MacPython binary distributions with an LDFLAGS configure 
option, as in
$PYTHONSRC/configure -C --enable-framework LDFLAGS=-Wl,-x

This has suddenly started failing with a very mysterious error 
message. When the
make tries to build the extension modules I get
running build
running build_ext
usage: setup.py [options]
setup.py: error: no such option: -W

Could this somehow be caused by your fix?

Yep, it's my doing.  I bet optparse is raising an error since it doesn't 
have options for -W1 or -x registered with the parser.  Anyone off the 
top of their head know how to cause optparse to just skip over options 
it doesn't know about?

OK, rev. 1.210 has my fix.  Now I strip out double dashes (for long options) 
and any dashes preceding any options that setup.py doesn't care about before 
passing the string to optparse.  That way they just look like interspersed 
arguments to optparse and it just ignores them.

Tested it with your LDFLAGS value and it worked fine for me.
I am on vacation at the moment so I will deal with this when I get back 
this weekend.

So I lied and got to it sooner.  =)
Happy New Year to everyone.
-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] python-dev Summary for 2004-11-16 through 2004-11-30 [draft]

[Brett C.]

With school starting up again Monday and New Years being tomorrow I don't plan 
to send this out until Tuesday.

Hope everyone has a good New Years.
-Brett
---
=
Summary Announcements
=
PyCon_ is coming up!  Being held March 23-25 in Washington, DC, registration is 
now open at http://www.python.org/pycon/2005/register.html for credit card 
users (you can pay by check as well; see the general info page for the conference).

.. _PyCon: http://www.python.org/pycon/2005/
=
Summaries
=
-
Would you like the source with your function?
-
Would you like all functions and classes to contain a __pycode__ attribute that 
contains a string of the code used to compile that code object?  Well, that 
very idea was proposed.  You would use a command-line switch to turn on the 
feature in order to remove the memory and any performance overhead for the 
default case of not needing this feature.

Some might ask why this is needed when inspect.getsource and its ilk exist. 
The perk is that __pycode__ would always exist while inspect.getsource is a 
best attempt but cannot guarantee it will have the source.

Beyond a suggested name change to __source__, various people have suggested 
very different uses.  Some see it as a convenient way to save interpreter work 
easily and thus not lose any nice code snippet developed interactively.  Others 
see a more programmatic use (such as AOP "advice" injection).  Both are rather 
different and led to the thread ending on the suggestion that a PEP be written 
that specifies what the intended use-case to make sure that need is properly met.

Contributing threads:
  - `__pycode__ extension <>`__
===
Skipped Threads
===
- PEP 310 Status
- python 2.3.5 release?
  look for 2.3.5 possibly in January
- Current CVS, Cygwin and "make test"
- syntactic shortcut - unpack to variably sizedlist
  mostly discussed `last summary`_
- Python 2.4, MS .NET 1.1 and distutils
- Trouble installing 2.4
- Looking for authoritative documentation on packages, import & ihooks
  no docs exist, but feel free to write some!  =)
- String literal concatenation & docstrings
  literal string concatenation only works if the newline separating the 
strings is not significant to the parser
- print "%X" % id(object()) not so nice
  does 'id' need to return only a positive?  No, but it would be nice.
- Bug in PyLocale_strcoll
- Multilib strikes back
- File encodings
  file.write does not work with Unicode strings; have to decode them to 
ASCII on your own
___
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] Re: Zipfile needs?

[Brett C.]

Scott David Daniels wrote:
Brett C. wrote:
Scott David Daniels wrote:
I'm hoping to add BZIP2 compression to zipfile for 2.5.  My primary
motivation is that Project Gutenberg seems to be starting to use BZIP2
compression for some of its zips.  What other wish list things do
people around here have for zipfile?  I thought I'd collect input here
and make a PEP.
Encryption/decryption support.  Will most likely require a C extension 
since the algorithm relies on ints (or longs, don't remember) wrapping 
around when the value becomes too large.

I'm trying to use byte-block streams (iterators taking iterables) as
the basic structure of getting data in and out.  I think the encryption/
decryption can then be plugged in at the right point.  If it can be set
up properly, you can import the encryption separately and connect it to
zipfiles with a call.  Would this address what you want?  I believe
there is an issue actually building in the encryption/decryption in
terms of redistribution.
Possibly.  Encryption is part of the PKZIP spec so I was just thinking of 
covering that, not adding external encryption support.  It really is not overly 
complex stuff, just will want to do it in C for speed probably as Guido 
suggested (but, as always, I would profile that first to see if performance is 
really that bad).

-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] Please help complete the AST branch

[Brett C.]

Guido van Rossum wrote:
The AST branch has been "nearly complete" for several Python versions
now. The last time a serious effort was made was in May I believe, but
it wasn't enough to merge the code back into 2.4, alas.
It would be a real shame if this code was abandoned.
[SNIP]
So, I'm pleading. Please, someone, either from the established crew of
developers or a new volunteer (or more than one!), try to help out to
complete the work on the AST branch and merge it into 2.5.
[SNIP]
Please, anyone? Raymond? Neil? Facundo? Brett?
Funny you should send this out today.  I just did some jiggling with my 
schedule so I could take the undergrad language back-end course this quarter. 
This led to me needing to take a grad-level projects class in Spring.  And what 
was the first suggestion my professor had for that course credit in Spring?

Finish the AST branch.  I am dedicated to finishing the AST branch as soon as 
my thesis is finished, class credit or no.  I just can't delve into that large 
of a project until I get my school stuff in order.  But if I get to do it for 
my class credit I will be able to dedicate 4 units of work to it a week (about 
8 hours minimum).

Plus there is the running tradition of sprinting on the AST branch at PyCon.  I 
was planning on shedding my bug fixing drive at PyCon this year and sprinting 
with (hopefully) Jeremy, Neal, Tim, and Neil on the AST branch as a prep for 
working on it afterwards for my class credit.

Although if someone can start sooner than by all means, go for it!  I can find 
something else to get credit for (such as finishing my monster of a paper 
comparing Python to Java; 34 single-spaced pages just covering paradigm support 
and the standard libraries so far).  And obviously help would be great since it 
isn't a puny codebase (4,000 lines so far for the CST->AST and AST->bytecode code).

If anyone would like to see the current code, check out ast-branch from CVS 
(read the dev FAQ on how to check out a branch from CVS).  Read 
Python/compile.txt for an overview of how the thing works and such.

It will get done, just don't push for a 2.5 release within a month.  =)
-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] Please help complete the AST branch

[Brett C.]

Alex Martelli wrote:
On 2005 Jan 04, at 17:17, Jeremy Hylton wrote:
That's fine with me.  We had taken it to the compiler-sig when it
wasn't clear there was interest in the ast branch :-).

Speaking for myself, I have a burning interest in the AST branch (though 
I can't seem to get it correctly downloaded so far, I guess it's just my 
usual CVS-clumsiness and I'll soon find out what I'm doing wrong & fix 
it)
See http://www.python.org/dev/devfaq.html#how-can-i-check-out-a-tagged-branch 
on how to do a checkout of a tagged branch.

-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] Please help complete the AST branch

[Brett C.]

Jeff Epler wrote:
On Mon, Jan 03, 2005 at 06:02:52PM -0800, Brett C. wrote:
Although if someone can start sooner than by all means, go for it!
And obviously help would be great since it isn't a puny codebase
(4,000 lines so far for the CST->AST and AST->bytecode code).

And obviously knowing a little more about the AST branch would be
helpful for those considering helping.
Is there any relatively up-to-date document about ast-branch?  googling
about it turned up some pypy stuff from 2003, and I didn't look much
further.
Beyond the text file Python/compile.txt in CVS, nope.  I have tried to flesh 
that doc out as well as I could to explain how it all works.

If it doesn't answer all your questions then just ask here on python-dev (as 
the rest of this thread has seemed to agreed upon).  I will do my best to make 
sure any info that needs to work its way back into the doc gets checked in.

I just built the ast-branch for fun, and "make test" mostly worked.
8 tests failed:
test_builtin test_dis test_generators test_inspect test_pep263
test_scope test_symtable test_trace
6 skips unexpected on linux2:
test_csv test_hotshot test_bsddb test_parser test_logging
test_email
I haven't looked at any of the failures in detail, but at least
test_bsddb is due to missing development libs on this system
One more thing:  The software I work on by day has python scripting.
One part of that functionality is a tree display of a script.  I'm not
actively involved with this part of the software (yet).  Any comments on
whether ast-branch could be construed as helping make this kind of
functionality work better, faster, or easier?  The code we use currently
is based on a modified version of the parser which includes comment
information, so we need to be aware of changes in this area anyhow.
If by tree you mean execution paths, then yes, eventually.  When the back-end 
is finished the hope is to be able to export the AST to Python objects and thus 
have it usable in Python.  You could use the AST representation to display your 
tree.

-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] Subscribing to PEP updates

[Brett C.]

Nick Coghlan wrote:
Someone asked on python-list about getting notifications of changes to 
PEP's.

As a low-effort solution, would it be possible to add a Sourceforge 
mailing list hook just for checkins to the nondist/peps directory?

Call it python-pep-updates or some such beast. If I remember how checkin 
notifications work correctly, the updates would even come with automatic 
diffs :)

Probably not frequent or comprehensive enough, but I try to always have at 
least a single news item that clumps all PEP updates that python-dev gets 
notified about.

-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] proto-pep: How to change CPython's bytecode

[Brett C.]

OK, latest update with all suggest revisions (mention this is for CPython, 
section for known previous bytecode work).

If no one has any revisions I will submit to David for official PEP acceptance 
this weekend.

--
PEP: XXX
Title: How to change CPython's bytecode
Version: $Revision: 1.4 $
Last-Modified: $Date: 2003/09/22 04:51:50 $
Author: Brett Cannoon <[EMAIL PROTECTED]>
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: XX-XXX-
Post-History: XX-XXX-
Abstract

Python source code is compiled down to something called bytecode.  This
bytecode must implement enough semantics to perform the actions required by the
Language Reference [#lang-ref].  As such, knowing how to add, remove, or change
the bytecode is important to do properly when changing the abilities of the
Python language.
This PEP covers how to accomplish this in the CPython implementation of the
language (referred to as simply "Python" for the rest of this PEP).
Rationale
=
While changing Python's bytecode is not a frequent occurence, it still happens.
Having the required steps documented in a single location should make
experimentation with the bytecode easier since it is not necessarily obvious
what the steps are to change the bytecode.
This PEP, paired with PEP 306 [#PEP-306]_, should provide enough basic
guidelines for handling any changes performed to the Python language itself in
terms of syntactic changes that introduce new semantics.
Checklist
=
This is a rough checklist of what files need to change and how they are
involved with the bytecode.  All paths are given from the viewpoint of
``/cvsroot/python/dist/src`` from CVS).  This list should not be considered
exhaustive nor to cover all possible situations.
- ``Include/opcode.h``
This include file lists all known opcodes and associates each opcode
name with
a unique number.  When adding a new opcode it is important to take note
of the ``HAVE_ARGUMENT`` value.  This ``#define``'s value specifies the
value at which all opcodes that have a value greater than
``HAVE_ARGUMENT`` are expected to take an argument to the opcode.
- ``Lib/opcode.py``
Lists all of the opcodes and their associated value.  Used by the dis
module [#dis]_ to map bytecode values to their names.
- ``Python/ceval.c``
Contains the main interpreter loop.  Code to handle the evalution of an
opcode here.
- ``Python/compile.c``
To make sure an opcode is actually used, this file must be altered.
The emitting of all bytecode occurs here.
- ``Lib/compiler/pyassem.py``, ``Lib/compiler/pycodegen.py``
The 'compiler' package [#compiler]_ needs to be altered to also reflect
any changes to the bytecode.
- ``Doc/lib/libdis.tex``
The documentation [#opcode-list] for the dis module contains a complete
list of all the opcodes.
- ``Python/import.c``
Defines the magic word (named ``MAGIC``) used in .pyc files to detect if
the bytecode used matches the one used by the version of Python running.
This number needs to be changed to make sure that the running
interpreter does not try to execute bytecode that it does not know
about.
Suggestions for bytecode development

A few things can be done to make sure that development goes smoothly when
experimenting with Python's bytecode.  One is to delete all .py(c|o) files
after each semantic change to Python/compile.c .  That way all files will use
any bytecode changes.
Make sure to run the entire testing suite [#test-suite]_.  Since the
``regrtest.py`` driver recompiles all source code before a test is run it acts
a good test to make sure that no existing semantics are broken.
Running parrotbench [#parrotbench]_ is also a good way to make sure existing
semantics are not broken; this benchmark is practically a compliance test.
Previous experiments

Skip Montanaro presented a paper at a Python workshop on a peephole optimizer
[#skip-peephole]_.
Michael Hudson has a non-active SourceForge project named Bytecodehacks
[#Bytecodehacks]_ that provides functionality for playing with bytecode
directly.
References
==
.. [#lang-ref] Python Language Reference, van Rossum & Drake
   (http://docs.python.org/ref/ref.html)
.. [#PEP-306] PEP 306, How to Change Python's Grammar, Hudson
   (http://www.python.org/peps/pep-0306.html)
.. [#dis] dis Module
   (http://docs.python.org/lib/module-dis.html)
.. [#test-suite] 'test' package
   (http://docs.python.org/lib/module-test.html)
.. [#parrotbench] Parrotbench
   (ftp://ftp.python.org/pub/python/parrotbench/parrotbench.tgz,
   http://mail.python.org/pipermail/python-dev/2003-December/041527.html)
.. [#opcode-list] Python Byte Code Instructions
   (http://docs.python.org/lib/bytecodes.html)
.. [#skip-peephole]
http://www.foretec.com/python/workshops/1998-11/proceed

Re: [Python-Dev] frame.f_locals is writable

[Brett C.]

Shane Holloway (IEEE) wrote:
For a little background, I'm working on making an edit and continue 
support in python a little more robust.  So, in replacing references to 
unmodifiable types like tuples and bound-methods (instance or class), I 
iterate over gc.get_referrers.

So, I'm working on frame types, and wrote this code::
def replaceFrame(self, ref, oldValue, newValue):
for name, value in ref.f_locals.items():
if value is oldValue:
ref.f_locals[name] = newValue
assert ref.f_locals[name] is newValue
But unfortunately, the assert fires.  f_locals is writable, but not 
modifiable.  I did a bit of searching on Google Groups, and found 
references to a desire for smalltalk like "swap" functionality using a 
similar approach, but no further ideas or solutions.

While I am full well expecting the smack of "don't do that", this 
functionality would be very useful for debugging long-running 
applications.  Is this possible to implement in CPython and ports?  Is 
there an optimization reason to not do this?

So it would be doable, but it is not brain-dead simple if you want to keep the 
interface of a dict.  Locals, in the frame, are an array of PyObjects (see 
PyFrameObject->f_localsplus).  When you request f_locals that returns a dict 
that was created by a function that takes the array, traverses it, and creates 
a dict with the proper names (using PyFrameObject->f_code->co_varnames for the 
array offset -> name mapping).  The resulting dict gets stored in 
PyFrameObject->f_locals.  So it is writable as you discovered since it is just 
a dict, but it is not used in Python/ceval.c except for IMPORT_STAR; changes 
are just never even considered.  The details for all of this can be found in 
Objects/frameobject.c:PyFrame_FastToLocals() .

The interesting thing is that there is a corresponding PyFrame_LocalsToFast() 
function that seems to do what you want; it takes the dict in 
PyFrameObject->f_locals and propogates the changes into 
PyFrameObject->f_localsplus (or at least seems to; don't have time to stare at 
the code long enough to make sure it does that exactly).  So the functionality 
is there (and is in the API even).  It just isn't called explicitly except in 
two points in Python/ceval.c where you can't get at it.  =)

As to making changes to f_locals actually matter would require either coming up 
with a proxy object that is stored in f_locals instead of a dict and 
dynamically grab everything from f_localsplus as needed.  That would suck for 
performance and be a pain to keep the dict API.  So you can count that out.

Other option would be to add a function that either directly modified single 
values in f_localsplus, a function that takes a dict and propogates the values, 
or a function that just calls PyFrame_LocalsToFast() .

Personally I am against this, but that is because you would single-handedly 
ruin my master's thesis and invalidate any possible type inferencing one can do 
in Python without some semantic change.  But then again my thesis shows that 
amount of type inferencing is not worth the code complexity so it isn't totally 
devastating.  =)

And you are right, "don't do that".  =)
Back to the putrid, boggy marsh of JavaLand for me...
-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] redux: fractional seconds in strptime

[Brett C.]

Skip Montanaro wrote:
A couple months ago I proposed (maybe in a SF bug report)
http://www.python.org/sf/1006786
 that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module.  I've hit that
stumbling block again, this time in parsing files with timestamps that were
generated using datetime.time objects.  I hacked around it again (in
miserable fashion), but I really think this shortcoming should be addressed.
A couple possibilities come to mind:
1. Extend the %S format token to accept simple decimals that match
   the re pattern "[0-9]+(?:\.[0-9]+)".
2. Add a new token that accepts decimals as above to avoid overloading
   the meaning of %S.
3. Add a token that matches integers corresponding to fractional parts.
   The Perl DateTime module uses %N to match nanoseconds (wanna bet that
   was added by a physicist?).  Arbitrary other units can be specified
   by sticking a number between the "%" and the "N".  I didn't see an
   example, but I presume "%6N" would match integers that are
   interpreted as microseconds.
The problem I have always had with this proposal is that the value is 
worthless, time tuples do not have a slot for fractional seconds.  Yes, it 
could possibly be changed to return a float for seconds, but that could 
possibly break things.

My vote is that if something is added it be like %N but without the optional 
optional digit count.  This allows any separator to be used while still 
consuming the digits.  It also doesn't suddenly add optional args which are not 
supported for any other directive.

-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] redux: fractional seconds in strptime

[Brett C.]

Skip Montanaro wrote:
Brett> The problem I have always had with this proposal is that the
Brett> value is worthless, time tuples do not have a slot for fractional
Brett> seconds.  Yes, it could possibly be changed to return a float for
Brett> seconds, but that could possibly break things.
Actually, time.strptime() returns a struct_time object.  Would it be
possible to extend %S to parse floats then add a microseconds (or whatever)
field to struct_time objects that is available by attribute only?  In Py3k
it could worm its way into the tuple representation somehow (either as a new
field or by returning seconds as a float).
Right, it's a struct_time object; just force of habit to call it a time 
tuple.
And I technically don't see why a fractional second attribute could not be 
added that is not represented in the tuple.  But I personally would like to see 
struct_tm eliminated in Py3k and replaced with datetime usage.  My wish is to 
have the 'time' module stripped down to only the bare essentials that just 
don't fit in datetime and push everyone to use datetime for most things.

Brett> My vote is that if something is added it be like %N but without
Brett> the optional optional digit count.  This allows any separator to
Brett> be used while still consuming the digits.  It also doesn't
Brett> suddenly add optional args which are not supported for any other
Brett> directive.
I realize the %4N notation is distasteful, but without it I think you will
have trouble parsing something like
13:02:00.704
What would be the format string?  %H:%M:%S.%N would be incorrect.
Why is that incorrect?
-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] redux: fractional seconds in strptime

[Brett C.]

Skip Montanaro wrote:
>> I realize the %4N notation is distasteful, but without it I think you
>> will have trouble parsing something like
>> 
>> 13:02:00.704
>> 
>> What would be the format string?  %H:%M:%S.%N would be incorrect.

Brett> Why is that incorrect?
Because "704" represents the number of milliseconds, not the number of
nanoseconds.
I'm sure that in some applications people are interested in extremely short
time scales.  Writing out hours, minutes and seconds when all you are
concerned with are small fractions of seconds (think high energy physics)
would be a waste.  In those situations log entries like
704 saw proton
705 proton hit neutron
706 saw electron headed toward Saturn
might make perfect sense.  Parsing the time field entirely within
time.strptime would be at least clumsy if you couldn't tell it the scale of
the numbers you're dealing with.  Parsing with %N, %3N or %6N would give
different values (nanoseconds, milliseconds or microseconds).
Fine, but couldn't you also do a pass over the data after extraction to get to 
the actual result you want (so parse, and take the millisecond value and 
multiply by the proper scale)?  This feels like it is YAGNI, or at least KISS. 
 If you want to handle milliseconds because of the logging module, fine.  But 
trying to deal with all possible time parsing possibilities is painful and 
usually not needed.

Personally I am more inclined to add a new directive that acts as %S but allows 
for an optional decimal point, comma or the current locale's separator if it 
isn't one of those two which will handle the logging package's optional decimal 
output ('\d+([,.%s]\d+)?" % locale.localeconv()['decimal_point']).  Also 
doesn't break any existing code.

And an issue I forgot to mention for all of this is it will break symmetry with 
time.strftime().  If symmetry is kept then an extra step in strftime will need 
to be handled since whatever solution we do will not match the C spec anymore.

-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] a bunch of Patch reviews

[Brett C.]

Martin v. Löwis wrote:
I think Brett Cannon now also follows this rule; it
really falls short enough in practice because (almost)
nobody really wants to push his patch bad enough to
put some work into it to review other patches.
Yes, I am trying to support the rule, but my schedule is nutty right now so my 
turn-around time is rather long at the moment.

-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] python-dev Summary for 2004-12-01 through 2004-12-15 [draft]

[Brett C.]

Uh, life has been busy.
Will probably send this one out this weekend some time so please get 
corrections in before then.


=
Summary Announcements
=
PyCon_ 2005 is well underway.  The schedule is in the process of being 
finalized (just figuring out the order of the talks).  And there is still time 
for the early-bird registration price of $175 ($125 students) before it expires 
on January 28th.

Some day I will be all caught up with the Summaries...
.. _PyCon: http://www.pycon.org
=
Summaries
=
--
PEPS: those existing and gestating
--
[for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP' 
topic]
A proto-PEP covering the __source__ proposal from the `last summary`_ has been 
posted to python-dev.

`PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute 
modules contained within packages.

.. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 338: http://www.python.org/peps/pep-0338.html
Contributing threads:
  - `PEP: __source__ proposal <>`__
  - `PEP 338: Executing modules inside packages with '-m' <>`__
---
Deprecating modules
---
The xmllib module was deprecated but not listed in `PEP 4`_.  What does one do? 
 Well, this led to a long discussion on how to handle module deprecation.

With the 'warning' module now in existence, PEP 4 seemed to be less important. 
 It was generally agreed that listing modules in PEP 4 was no longer needed. 
It was also agreed that deleting deprecated modules was not needed; it breaks 
code and disk space is cheap.

It seems that no longer listing documentation and adding a deprecation warning 
is what is needed to properly deprecate a module.  By no longer listing 
documentation new programmers will not use the code since they won't know about 
it.  And adding the warning will let old users know that they should be using 
something else.

.. _PEP 4: http://www.python.org/peps/pep-0004.html
Contributing threads:
  - `Deprecated xmllib module <>`__
  - `Rewriting PEP4 <>`__
--
PR to fight the idea that Python is "slow"
--
An article_ in ACM TechNews that covered 2.4 had several mentions that Python 
was "slow" while justifying the slowness (whether it be flexibility or being 
fast enough).  Guido (rightfully) didn't love all of the "slow" mentions which 
I am sure we have all heard at some point or another.

The suggestions started to pour in on how to combat this.  The initial one was 
to have a native compiler.  The thinking was that if we compiled to a native 
executable that people psychologically would stop the association of Python 
being interpreted which is supposed to be slow.  Some people didn't love this 
idea since a native compiler is not an easy thing.  Others suggested including 
Pyrex with CPython, but didn't catch on (maintenance issue plus one might say 
Pyrex is not the most Pythonic solution).  This didn't get anywhere in the end 
beyond the idea of a SIG about the various bundling tools (py2app, py2exe, etc.).

The other idea was to just stop worrying about speed and move on stomping out 
bugs and making Python functionally more useful.  With modules in the stdlib 
being rewritten in C for performance reasons it was suggested we are putting 
out the perception that performance is important to us.  Several other people 
also suggested that we just not mention speed as a big deal in release notes 
and such.

This also tied into the idea that managers don't worry too much about speed as 
much as being able to hire a bunch of Python programmers.  This led to the 
suggestion of also emphasizing that Python is very easy to learn and thus is a 
moot point.  There are a good number of Python programmers, though; Stephan 
Deibel had some rough calculations that put the number at about 750K Python 
developers worldwide (give or take; rough middle point of two different 
calculations).

.. _article: http://gcn.com/vol1_no1/daily-updates/28026-1.html
Contributing threads:
  - `2.4 news reaches interesting places <>`__
===
Skipped Threads
===
- MS VC compiler versions
- Any reason why CPPFLAGS not used in compiling?
  Extension modules now compile with directories specified in the LDFLAGS 
and CPPFLAGS env vars
- adding key argument to min and max
  min and max now have a 'key' argument like list.sort
- Unicode in doctests
- SRE bug and notifications
- PyInt_FromLong returning NULL
- PyOS_InputHook enhancement proposal
- The other Py2.4 issue
- MinGW And The other Py2.4 issue
- Supporting Third Party Modules
- Python in education
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://

Re: [Python-Dev] I think setup.py needs major rework

[Brett C.]

Fred L. Drake, Jr. wrote:
On Tuesday 25 January 2005 23:30, Skip Montanaro wrote:
 > Python's setup.py has grown way out of control.  I'm trying to build
 > and install Python 2.4.0 on a Solaris system with Tcl/Tk installed in a
 > non-standard place and I can't figure out the incantation to tell setup.py
 > to look where they are installed.
...
 > This might be an excellent sprint topic for PyCon.
Indeed it would be!
... and now it is listed as one.  Started a section on the sprint wiki page for 
orphaned sprint topics with a subsection on core stuff.  Listed a rewrite of 
setup.py along with a rewrite of site.py and the usual bug/patch squashing.

URL is http://www.python.org/moin/PyConDC2005/Sprints for those not wanting to 
go hunting for it.

-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: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

[Brett C.]

Neal Norwitz wrote:
On Wed, 26 Jan 2005 09:47:41 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[SNIP]
Any ideas how we could start to realize some benefits of Py3.0 before
it arrives?  I'm not sure if this is worth it, if it's premature, or
if there are other ways to acheive the goal of easing transition for
users and simplifying developers tasks (by spreading over a longer
period of time) and reducing the possibility of not fixing warts.
The way I always imagined Python 3.0 would come about would be through preview 
releases.  Once the final 2.x version was released and went into maintennance 
we would start developing Python 3.0 .  During that development, when a major 
semantic change was checked in and seemed to work we could do a quick preview 
release for people to use to see if the new features up to that preview release 
would break their code.

Any other way, though, through concurrent development, seems painful.  As you 
mentioned, Neal, branches require merges eventually and that can be painful.  I 
suspect people will just have to put up with a longer dev time for Python 3.0 . 
 That longer dev time might actually be a good thing in the end.  It would 
enable us to really develop a very stable 2.x version of Python that we all 
know will be in use for quite some time by old code.

-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] python-dev Summary for 2004-12-16 through 2004-12-31 [draft]

[Brett C.]

Nice and short summary this time.  Plan to send this off Wednesday or Thursday 
so get corrections in before then.

--
=
Summary Announcements
=
You can still `register `__ for 
`PyCon`_.  The `schedule of talks`_ is now online.  Jim Hugunin is lined up to 
be the keynote speaker on the first day with Guido being the keynote on 
Thursday.  Once again PyCon looks like it is going to be great.

On a different note, as I am sure you are all aware I am still about a month 
behind in summaries.  School this quarter for me has just turned out hectic.  I 
think it is lack of motivation thanks to having finished my 14 doctoral 
applications just a little over a week ago (and no, that number is not a typo). 
 I am going to for the first time in my life come up with a very regimented 
study schedule that will hopefully allow me to fit in weekly Python time so as 
to allow me to catch up on summaries.

And this summary is not short because I wanted to finish it.  2.5 was released 
just before the time this summary covers so most stuff was on bug fixes 
discovered after the release.

.. _PyCon: http://www.pycon.org/
.. _schedule of talks: http://www.python.org/pycon/2005/schedule.html
===
Summary
===
-
PEP movements
-
I introduced a `proto-PEP 
`__ to 
the list on how one can go about changing CPython's bytecode.  It will need 
rewriting once the AST branch is merged into HEAD on CVS.  Plus I need to get a 
PEP number assigned to me.  =)

Contributing threads:
  - ` proto-pep: How to change Python's bytecode <>`__

Handling versioning within a package

The suggestion of extending import syntax to support explicit version 
importation came up.  The idea was to have something along the lines of 
``import foo version 2, 4`` so that one can have packages that contain 
different versions of itself and to provide an easy way to specify which 
version was desired.

The idea didn't fly, though.  The main objection was that import-as support was 
all you really needed; ``import foo_2_4 as foo``.  And if you had a ton of 
references to a specific package and didn't want to burden yourself with 
explicit imports, one can always have a single place before codes starts 
executing doing ``import foo_2_4; sys.modules["foo"] = foo_2_4``.  And that 
itself can even be lower by creating a foo.py file that does the above for you.

You can also look at how wxPython handles it at 
http://wiki.wxpython.org/index.cgi/MultiVersionInstalls .

Contributing threads:
  - `Re: [Pythonmac-SIG] The versioning question... <>`__
===
Skipped Threads
===
- Problems compiling Python 2.3.3 on Solaris 10 with gcc 3.4.1
- 2.4 news reaches interesting places
 see `last summary`_ for coverage of this thread
- RE: [Python-checkins] python/dist/src/Modules posixmodule.c, 2.300.8.10, 
2.300.8.11
- mmap feature or bug?
- Re: [Python-checkins]	python/dist/src/Pythonmarshal.c, 1.79, 1.80
- Latex problem when trying to build documentation
- Patches: 1 for the price of 10.
- Python for Series 60 released
- Website documentation - link to descriptor information
- Build extensions for windows python 2.4 what are the compiler rules?
- Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209
- Zipfile needs?
fake 32-bit unsigned int overflow with ``x = x & 0xL`` and signed 
ints with the additional ``if x & 0x8000L: x -= 0x1L`` .
- Re: [Python-checkins] python/dist/src/Mac/OSX	fixapplepython23.py, 1.1, 1.2
___
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-dev Summary for 2004-12-16 through 2004-12-31 [draft]

[Brett C.]

Paul Moore wrote:
On Mon, 31 Jan 2005 14:02:20 -0800, Brett C. <[EMAIL PROTECTED]> wrote:
2.5 was released just before the time this summary covers so most stuff was on 
bug
fixes discovered after the release.

Give Guido the time machine keys back!
Fine, but I was going to go back in time, win the lottery, and give so much 
money to the PSF that a bunch of people were going to work on Python full-time 
for the rest of their lives.  It's your fault, Paul, that isn't going to happen 
now.  =)

I assume you meant 2.4, or is this a blatant attempt to get back ahead
of schedule with summaries? :-)
=)  No, it's a typo.  Problem of always using and working on 2.5 but having to 
remember when I am dealing with older versions.

Paul.
PS If you look in this month's python-dev archives, you'll see
evidence of /F's last attempt to steal the time machine, with a
message posted from the "far future" of Feb 23rd, 2005. He clearly
stalled the machine, as he posted from an alternate reality. Let this
be a warning!
Will actually be nice to finally not have to automatically skip the first line 
in the archive page thanks to that funky email.

-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] redux: fractional seconds in strptime

[Brett C.]

Everyone went silent on this topic.  Does this mean people just stopped caring 
(which I doubt since I know Skip wants this bad enough to bring it up every so 
often)?  Was it the issue of symmetry with strftime?

I am willing to add this (albeit the simple way I proposed in my last email on 
this thread) but I obviously don't want to bother if no one wants it or likes 
my proposed solution.

-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] python-dev Summary for 2005-01-01 through 2005-01-15 [draft]

[Brett C.]

Wow, another summary out the same week as the previous one!  Perk of keeping 
things short and to the point.  Then again keeping them this simple and short 
begs the question of whether the summaries are worth it still at that point.

Regardless, probably will send this one out Saturday or Sunday so corrections 
need to get in by then.

-
=
Summary Announcements
=
PyCon_ will be upon us come late March!  Still time to plan to go.
A warning on the thoroughness off this summary is in order.  While trying to 
delete a single thread of email I managed to accidentally delete my entire 
python-dev mailbox.  I did the best I could to retrieve the emails but it's 
possible I didn't resuscitate all of my emails, so I may have overlooked something.

.. _PyCon: http://www.pycon.org/
===
Summary
===
-
PEP movements
-
.. tip:: PEP updates by email are available as a topic from the 
`Python-checkins`_ mailing list.

`PEP 246`_ was a major topic of discussion during the time period covered by 
this summary.  This all stemmed from `Guido's blog`_ entries on optional type 
checking. This led to a huge discussion on many aspects of protocols, 
interfaces, and adaptation and the broadening of this author's vocabulary to 
include "Liskov violation".

"Monkey typing" also became a new term to know thanks to Phillip J. Eby's 
proto-PEP on the topic (found at 
http://peak.telecommunity.com/DevCenter/MonkeyTyping).  Stemming from the 
phrase "monkey see, monkey do", it's Phillip version of taking PEP 246 
logically farther (I think; the whole thing is more than my currently 
burned-out-on-school brain can handle right now).

.. _Python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 246: http://www.python.org/peps/pep-0246.html
.. Guido's blog: http://www.artima.com/weblogs/index.jsp?blogger=guido
Contributing threads:
  - `getattr and __mro__ <>`__
  - `Son of PEP 246, redux <>`__
  - `PEP 246: lossless and stateless <>`__
  - `PEP 246: LiskovViolation as a name <>`__
  - `"Monkey Typing" pre-PEP, partial draft <>`__

Optional type checking: how to inadvertently cause a flame war worse than 
decorators

`Guido's blog`_ had comments on the idea of adding optional static type 
checking to Python.  While just comments in a blog, it caused a massive 
response from people, mostly negative from what I gathered.  After Guido 
discussed things some more it culminated in a blog entry found at 
http://www.artima.com/weblogs/viewpost.jsp?thread=87182 that lays out what his 
actual plans are.  I highly recommend reading it since it suggests adding 
optional run-time type checking for function arguments along with some other 
proposals.

All of this led to `PEP 246`_ getting updated.  For some more details on that 
see the `PEP movements`_ section of this summary.

And if there is a lesson to be learned from all of this, it's that when Alex 
Martelli and Phillip J. Eby start a technical discussion it's going to be long, 
in-depth, complex, and lead to my inbox being brimming in python-dev email.

--
Let's get the AST branch done!
--
Guido posted an email to the list stating he would like to to make progress 
towards integrating "things like type inferencing, integrating PyChecker, or 
optional static type checking" into Python.  In order to make that easier he 
put out a request that people work on the AST branch and finish it.

For those that don't know about Python's back-end, the compiler as it stands 
now takes the parse tree from the parser and emits bytecode directly from that. 
 This is far from optimal since the parse tree is more verbose than needed and 
it is not the easiest thing to work with.

The AST branch attempts to fix this by taking a more traditional approach to 
compiling.  This means the parse tree is used to generate an AST (abstract 
syntax tree; and even more technically could be considered a control flow graph 
in view of how it is implemented) which in turn is used to emit bytecode.  The 
AST itself is much easier to work with when compared to the parse tree; better 
to know you are working with an 'if' guard thanks to it being an 'if' node in 
the AST than checking if the parse tree statement you are working with starts 
with 'if' and ends with a ':'.

While all of this sounds great, the issue is the AST branch is not finished 
yet.  It is not entirely far off, but new features from 2.4 (decorators and 
generator expressions) need to be added along with more bug fixing and clean up.

This means the AST branch is going to get finished for 2.5 somehow.  But help 
is needed.  While the usual suspects who have previously contributed to the 
branch are hoping to finish

[Python-Dev] discourage patch reviews to the list? (was: Patch review: [ 1098732 ])

[Brett C.]

BJörn Lindqvist wrote:
I'd like to help develop Python for fun and profit and I've heard that
posting patch reviews to python-dev is a good way to contribute. So
here goes:
Are we actually promoting this?  I am fine with people doing this when they 
have done five reviews and want their specific patch looked at (personally I 
prefer when people do it in a single email, but I can live with individual ones).

But if people don't have that in mind, should we not be encouraging this?  I 
mean it seems to be defeating the purpose of SF and having the various mailing 
lists that send out updates on SF posts.

-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] discourage patch reviews to the list?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
 > But if people don't have that in mind, should we not be encouraging
this?  I mean it seems to be defeating the purpose of SF and having 
the various mailing lists that send out updates on SF posts.
[SNIP]
Björn did post his comment to SF, and a summary to python-dev. I
personally think this is a good strategy: it puts focus on things
that should be worked on.
Let me explain why I think that these patches should be worked on:
- it might be that the analysis of the patch suggests that the patch
  should be rejected, as-is.
[SNIP]
- it might be that the analysis suggests changes.
[SNIP]
- it might be that the analysis recommend acceptance.
[SNIP]
All valid points, but I also don't want people to suddenly start posting 
one-liners or bug posts.

I guess it comes down to a signal-to-noise ratio and if the level of signal we 
are currently getting will hold.  If we say it is okay for people to send in 
patch reviews *only* and not notifications of new patches, bug reports, or bug 
reviews, then I can handle it.

To put it the other way 'round: should we only discuss changes on
python-dev which *don't* have patches on SF I don't think
so.
And neither do I.  I just don't want a ton of random emails on python-dev that 
really belong in the SF tracker instead.  Reason why we don't tend to take 
direct bug reports in email unless there is a question over semantics.

Furthermore, this strategy exposes the reviewer. A reviewer is
somebody who will potentially get write access to the tracker,
and perhaps CVS write access. A reviewer who wants to contribute
in this way regularly clearly needs to gain the trust of other
contributors, and posting smart, valuable, objective, balanced
reviews on contributed patches is an excellent way to gain such
trust (likewise, posting reviews which turn out to be flawed
is a way to find out that the reviewer still needs to learn
things before he can be trusted).
That is a very good point.  Guess I am softening on my rejection to this.  
=)
If people in general agree to this idea of having people post patch reviews to 
python-dev I will update the dev intro essay to reflect all of this.  I will 
also add a mention about the 5-1 patch review deal.

[SNIP]
P.S. These remarks are mostly of general nature - I haven't
actually studied yet Björn's review (but I leave it in my
inbox so I can get back to it next week).
Same here.  I didn't mean to single out Björn in any way.  He just happened to 
trigger an email out of me.  =)

-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] Five review rule on the /dev/ page?

[Brett C.]

[removed pydotorg from people receiving this email]
Aahz wrote:
On Thu, Feb 17, 2005, Skip Montanaro wrote:
I am frantically trying to get ready to be out of town for a
week of vacation.  Someone sent me some patches for datetime
and asked me to look at them.  I begged off but referred him to
http://www.python.org/dev/ and made mention of the five patch review
idea.  Can someone make sure that's explained on the /dev/ site?

This should go into Brett's survey of the Python dev process, not as
official documentation.  It's simply an offer made by some of the
prominent members of python-dev.
I am planning on adding that blurb in there.
Actually, while I have everyone's attention, I might as well throw an idea out 
there about sprucing up yet again the docs on contributing.  I was thinking of 
taking the current dev intro and have it just explain how things basically work 
around here.  So the doc would become more of just a high-level overview of how 
we dev the language.

But I would cut out the helping out section and spin that into another doc that 
would go into some more detail on how to make a contribution.  So this would 
specify in more detail how to report a bug, how to comment on one, etc. (same 
goes for patches).  This is where I would stick the 5-for-1 deal.

Lastly, write up a doc that covers what one with CVS checkin rights needs to do 
when checking in code.  So how one goes about getting checkin rights, getting 
initial checkins OK'ed by others, and then the usual steps taken for a checkin.

Sound worth it to people?  Not really needed so go back and do your homework, 
Brett?  What?

-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] Fixing _PyEval_SliceIndex so that integer-like objects can be used

[Brett C.]

Travis Oliphant wrote:
Hello again,
There is a great discussion going on the numpy list regarding a proposed 
PEP for multidimensional arrays that is in the works.

During this discussion as resurfaced regarding slicing with objects that 
are not IntegerType objects but that
have a tp_as_number->nb_int method to convert to an int.
Would it be possible to change

_PyEval_SliceIndex  in ceval.c
so that rather than throwing an error if the indexing object is not an 
integer, the code first checks to see if the object has a
tp_as_number->nb_int method and calls it instead.

You would also have to change apply_slice() since that also has a guard for 
checking the slice arguments are either NULL, int, or long objects.

But I am +1 with it since the guard is already there for ints and longs to 
handle those properly and thus the common case does not slow down in any way. 
As long as it also accepts Python objects that define __int__ and not just C 
types that have the nb_int slot defined I am okay with this idea.

-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] Store x Load x --> DupStore

[Brett C.]

Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
[SNIP]
And whatever happened to CALL_METHOD?

It didn't work as an optimization, as far as I remember.  I think the
patch is on SF somewhere.  Or is a branch in CVS?  Oh, it's patch
#709744.

Do we need a tp_callmethod that takes an argument array, length, and
keywords, so that we can skip instancemethod allocation in the
common case of calling a method directly?

Hmm, didn't think of that, and I don't think it's how the CALL_ATTR
attempt worked.  I presume it would need to take a method name too :)
CALL_ATTR basically replaced ``LOAD_ATTR; CALL_FUNCTION`` with a single opcode. 
 Idea was that the function creation by the LOAD_ATTR was a wasted step so 
might as well just skip it and call the method directly.

Problem was the work required to support both classic and new-style classes. 
Now I have not looked at the code since it was written back at PyCon 2003 and I 
was a total newbie to the core's C code at that point and I think Thomas said 
it had been two years since he did any major core hacking.  In other words it 
could possibly have been done better.  =)

-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] What about CALL_ATTR?

[Brett C.]

Reinhold Birkenfeld wrote:
While rummaging in the old patches, I found this:
"""
The result of the PyCore sprint of me and Brett: the CALL_ATTR opcode
(LOAD_ATTR and CALL_FUNCTION combined) that skips the PyMethod creation
and destruction for classic classes (but not newstyle classes, yet.)
The code is somewhat rough yet, it needs commenting, some renaming, and
most importantly testing. It seems to work, however, and provides
between a 35% and 5% speedup. (5% in 'average' code, up to 35% in
instance method calls and instance creation alone.) It also needs to be
updated to include newstyle classes. I will likely work on this on the
flight home.
"""
(patch #709744)
How is the status of this? Sounds promising, I'd say...
See my reply in the "Store x Load x -->  DupStore" thread at 
http://mail.python.org/pipermail/python-dev/2005-February/051725.html .

Basically Thomas discovered that it was slower when used with new-style 
classes.  But this was almost two years ago with Thomas having not done hacking 
on the core for two years IIRC and me having practically zero experience.

-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] __str__ vs. __unicode__

[Brett C.]

Walter Dörwald wrote:
M.-A. Lemburg wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
 > [...]
__str__ and __unicode__ as well as the other hooks were
specifically added for the type constructors to use.
However, these were added at a time where sub-classing
of types was not possible, so it's time now to reconsider
whether this functionality should be extended to sub-classes
as well.

So can we reach consensus on this, or do we need a
BDFL pronouncement?

I don't have a clear picture of what the consensus currently
looks like :-)
If we're going for for a solution that implements the hook
awareness for all  hooks, I'd be +1 on that.
If we only touch the __unicode__ case, we'd only be created
yet another special case. I'd vote -0 on that.
 > [...]
Here's the patch that implements this for int/long/float/unicode:
http://www.python.org/sf/1109424
Any movement on this?  +1 for making things work like str; if a subclass 
overrides __str__ it should use that method.  If correctness of what is 
returned is a worry then a check could be tossed in before the value is returned.

-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] __str__ vs. __unicode__

[Brett C.]

Walter Dörwald wrote:
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
I don't have a clear picture of what the consensus currently
looks like :-)
If we're going for for a solution that implements the hook
awareness for all  hooks, I'd be +1 on that.
If we only touch the __unicode__ case, we'd only be created
yet another special case. I'd vote -0 on that.
[...]

Here's the patch that implements this for int/long/float/unicode:
http://www.python.org/sf/1109424

Any movement on this?  +1 for making things work like str; if a 
subclass overrides __str__ it should use that method.  If correctness 
of what is
returned is a worry then a check could be tossed in before the value 
is returned.

It already works that way:
Python 2.5a0 (#1, Feb 24 2005, 16:25:04)
[GCC 2.96 2731 (Red Hat Linux 7.3 2.96-113)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> class u(unicode):
...  def __unicode__(self): return 42
Well then I am +1 on doing this.
Since this is a semantic change probably need Guido to OK this?
-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] __str__ vs. __unicode__

[Brett C.]

Brett C. wrote:
Walter Dörwald wrote:
Brett C. wrote:
Walter Dörwald wrote:
M.-A. Lemburg wrote:
[...]
I don't have a clear picture of what the consensus currently
looks like :-)
If we're going for for a solution that implements the hook
awareness for all  hooks, I'd be +1 on that.
If we only touch the __unicode__ case, we'd only be created
yet another special case. I'd vote -0 on that.
[SNIP]
Since this is a semantic change probably need Guido to OK this?
... which we now have.  Assigned the patch to myself.  I will get to it 
eventually.
-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] python-dev Summary for 2005-01-16 through 2005-01-31 [draft]

[Brett C.]

A month late.  Glad I don't get paid for this or I probably would have been 
fired by now.  =)

For this summary draft I am bringing back the header this one time in hopes of 
getting some proof-reading of it.  I did a major restructuring with some 
accompanying rewrites to make it easier to navigate.  Details are in the 
Summary Announcements section.  And you can ignore XXX and any %s points since 
this is just a direct paste of the template I use for generating the Summaries.

I am hoping to get this summary out either Saturday or Sunday since I am 
anxious to try out AMK's new RSS feed for the Summaries (see the Intro section 
or Summary Announcements for the URI).


python-dev Summary for %(start_ISO_date)s through %(end_ISO_date)s

.. contents::
=
Intro
=
This is a summary of traffic on the `python-dev mailing list`_ from
%(start_traditional_date)s through %(end_traditional_date)s.
It is intended to inform the wider Python community of on-going
developments on the list on a semi-monthly basis.  An archive_ of
previous summaries is available online.
An `RSS feed`_ of the titles of the summaries is available.
You can also watch comp.lang.python or comp.lang.python.announce for
new summaries (or through their email gateways of python-list or
python-announce, respectively, as found at http://mail.python.org).
This is the XXX summary written by Brett Cannon (XXX).
To contact me, please send email to brett at python.org.  Do *not*
post to comp.lang.python if you wish to reach me.
The `Python Software Foundation`_ is the non-profit organization that
holds the intellectual property for Python.  It also tries to forward
the development and use of Python.  If you find the python-dev Summary
helpful please consider making a donation.  You can make a donation at
http://python.org/psf/donations.html .  Every penny helps so even a
small donation with a credit card, check, or by PayPal helps.
If you are looking for a way to expand your knowledge of Python's
development and inner-workings, consider writing the python-dev
Summaries yourself!  I am willing to hand over the reins to someone
who is willing to do a comparable or better job of writing the
Summaries.  If you are interested, please email me at
brett at python.org.

Commenting on Topics

To comment on anything mentioned here, just post to
`comp.lang.python`_ (or email python-list@python.org which is a
gateway to the newsgroup) with a subject line mentioning what you are
discussing.  All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on
something.  And if all of this really interests you then get involved
and join `python-dev`_!
-
How to Read the Summaries
-
The in-development version of the documentation for Python can be
found at http://www.python.org/dev/doc/devel/ and should be used when
looking up any documentation on new code; otherwise use the current
documentation as found at http://docs.python.org/ .  PEPs (Python
Enhancement Proposals) are located at http://www.python.org/peps/ .
To view files in the Python CVS online, go to
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ .  Reported
bugs and suggested patches can be found at the SourceForge_ project
page.
Please note that this summary is written using reStructuredText_.
Any unfamiliar punctuation is probably markup for reST_ (otherwise it
is probably regular expression syntax or a typo =); you can safely
ignore it.  I do suggest learning reST, though; it's simple and is
accepted for `PEP markup`_ and can be turned into many different
formats like HTML and LaTeX.  Unfortunately, even though reSt is
standardized, the wonders of programs that like to reformat text do
not allow me to guarantee you will be able to run the text version of
this summary through Docutils_ as-is unless it is from the
`original text file`_.
.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _PEP Markup: http://www.python.org/peps/pep-0012.html
.. _Docutils: http://docutils.sf.net/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. _last summary: http://www.python.org/dev/summary/%(html_prev_summary)s
.. _original text file: http://www.python.org/dev/summary/%(ht_name)s
.. _archive: http://www.python.org/dev/summary/
.. _RSS feed: http://www.python.org/dev/summary/channews.rdf

=
Summary Announcements
=
-
School sure likes to destroy my free time
-
A month late, that much clo

[Python-Dev] OK, time to retire (was: Re: python-dev Summary for 2005-01-16 through 2005-01-31)

[Brett C.]

Steve Holden wrote:
Michele Simionato wrote [on c.l.py]:
Brett Cannon:
[... python-dev summary ... boilerplate change ...]
+1 for this idea. The summary looks much better now :)
Keep the good work going,
Sorry, but i have to disagree. I hope you won't take this reply 
personally, Michele, since it's directed to all c.l.py readers, as well 
as (particularly) at Python users who [unlike you] are mostly take and 
rather less give. Although this is inherently the nature of open source, 
in certain cases this can be taken too far.

[SNIP]
Now, the reason for this specific rant is this: I can tell a cry for 
help when I see one. Brett has done a magnificent job of providing 
python-dev summaries since Andrew decided he'd had enough, and he is to 
be congratulated for it. I managed to offload another bunch of work on 
him (moderation of various troublesome PyCon mailing lists), but at 
least I was able to recompense him by letting him into PyCon for nothing.

[SNIP]
But frankly, I think it's time someone else stood up and said "Brett, 
you've done a magnificent job. Hesitant though I am about replacing you, 
I would like to volunteer for the task, because only when you are free 
from the burden of writing the python-dev summaries will we see what 
else you are capable of". Since I am at best an intermittent reader of 
python-dev I can say this without fear of having to stand up myself.

[SNIP]
[I am going to use this to reply to both Steve and Martin]
As Steve mentioned above, he can spot a cry for help when he sees one.  I think 
the problem is that I am a total sucker when it comes to the Python community 
and python-dev.

Anyone who has been on the python-dev list for as long as I have been a 
participant has most likely seen my almost yearly "thank you" emails I send the 
list (which there will probably be another one of once I choose where I am 
going to pursue my doctorate; I have acceptances but I am still waiting to here 
back from 9 more schools).  Usually it is just me gushing to python-dev, 
thanking the list for how Python has gotten me where I am today.  And that 
statement is completely sincere; python-dev has sculpted me into the programmer 
that I am (does this mean I can blame python-dev for my own buggy code?  =). 
And for that I will be eternally grateful to all of the wonderful people I have 
gotten to work with and know on this list.

It has also made me want to help people to get involved on python-dev in hopes 
others would benefit from python-dev the same way I have.  Granted, python-dev 
tends not to attract people like I was when I started getting involved (a 
philosophy degree and 4 CS courses does not equal a good programmer by default 
 =), but I have always hoped that through my efforts some other people could 
come to enjoy hacking on Python, learn some things, and advance the language.

But I think the big problem is that the Summaries have become a "gift" in the 
truest sense of the word.  I lost all personal benefit from the Summaries over 
a year ago.  Initially I learned a ton from all of the reading I was doing and 
the research required to understand what the heck people were talking about. 
But I have graduated from "The School of Hard Knocks".  At this point I do the 
Summaries entirely altruistically, giving back what I can to the community in a 
way that I know benefits many people which happens to have zero benefit to me now.

The Summaries consume what little free time I do have for Python which is 
unfortunate.  I have always hoped I would get to the point in my programming 
abilities that I would be a larger asset to python-dev as a programmer than as 
a writer.  I would like to think I have reached that point finally after my 
over two and a half years on the list (I can't believe I first posted to the 
list on June 17, 2002!).

So, to make sure I don't squander what time I do have for Python waiting for a 
possible replacement that might never come, I have decided that I am going to 
stop doing the python-dev Summaries after PyCon; the Summary covering the last 
half of March 2005 will be it for me.  Hopefully I will be more valuable as an 
active participant on python-dev again instead of as a passive listener who 
just happens to chime in on occasion and squash a simple bug when I am 
procrastinating from doing my homework.

This has been a long time coming and I needed a swift kick in the ass to 
finally get me to stop.  I thank you, Steve, for giving me that kick like the 
English gentleman you are.  =)

-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] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]

[Brett C.]

OK, so this one is really short.  Beyond the fact that I am probably doing this 
too late at night I also want to give the three people who have stepped forward 
to take over for me when I stopped writing the Summaries multiple chances to 
pick up on any of the Skipped Threads or even flesh out any of my thread 
summaries more.  I have asked them to post their writing here to make the 
choosing of a successor a little on the open side.

Hope to send this out Sunday night.
---
=
Summary Announcements
=
--
Giving myself a gold watch
--
As some of you may have already heard or read, I am retiring from writing the 
python-dev Summaries after sending out the March 16 - 31 summary.  It has been 
a long time coming and it required a kick in the ass (graciously supplied by 
Steve Holden) to finally make me let go of doing this and let someone else take 
over.

The joy of the Summaries has dwindled over the 2.5 years I have been doing 
this.  I was only doing them to be helpful.  But now I would rather put my time 
and effort I have for Python into coding work rather than the Summaries.  I 
would like to think I can be more productive and helpful as a programmer than a 
writer.  And so there will only be three more regular Summaries after this 
written by yours truly.

But do not worry about the Summaries dying!  When I announced this (see 
http://mail.python.org/pipermail/python-dev/2005-March/051823.html for the 
thread that led to this), three individuals stepped forward to pick up the work 
once I step down.  Steven Bethard, Tony Meyer, and Tim Lesher are being 
considered.  I honestly have no clue how the heck I am going to choose between 
the three of them.

As for my last Summary, expect a more expository one with my random thoughts on 
PyCon, Python, and anything else that comes to mind that I feel like using this 
space to abuse.  You have Scott David Daniels to thank for that format idea for 
my final hurrah.


Go to PyCon!

I just booked my hotel room for PyCon_.  You going to be there so I can shake 
your hand, thanking you for supporting Python?

.. _PyCon: http://www.pycon.org/
=
Summaries
=
-
Python Security Response Team founded
-
For those of you who don't know, a security hole was found in XML-RPC servers 
in the stdlib that use register_instance; details at 
http://www.python.org/security/PSF-2005-001/ .

In response to this, Guido has now formed the 'Python Security Response Team`_. 
 This group's job is to respond to any and all security issues that come up as 
quickly as possible and to issue a patch in a timely fashion.

.. _Python Security Response Team: http://www.python.org/security/
Contributing threads:
  - `Wanted: members for Python Security Response Team <>`__
--
Licensing issues in the stdlib
--
It was reported to python-dev that 'profiler' and 'md5 do not conform to the 
Debian Free Software Guidelines.  The specific issue was derived works using 
Python.  This is obviously not a good thing.

Things are in the works, though.  The hope is to get the copyrights signed over 
and all of this cleared up.  At worst the modules will be replaced with code 
licensed to the Python Software Foundation.  If you care to accelerate this by 
writing replacements please do so.

Contributing threads:
  - `license issues with profiler.py and md5.h/md5c.c <>`__
===
Skipped Threads
===
+ complex I/O problem
+ Is msvcr71.dll re-redistributable?
+ Son of PEP 246, redux
+ Re: PEP 246: LiskovViolation as a name
+ 2.3.5 and 2.4.1 release plans
+ Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15
+ list of constants -> tuple of constants
+ Other library updates
+ Re: python/dist/src/Lib rfc822.py,1.78,1.79
+ Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars
+ Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344
+ Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39
+ ViewCVS on SourceForge is broken
+ builtin_id() returns negative numbers
+ Clarification sought about including a multidimensional array object into 
Python core
___
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-dev Summary for 2005-02-01 through 2005-02-14 [draft]

[Brett C.]

Aahz wrote:
Both entries so far look very good.  Perhaps writing python-dev summaries
could be a rotating position?
Good idea that several people have now suggested to me.  I have emailed Tim, 
Steve, and Tony to see what they think.  It wouldn't surprise me if this 
happens if for any other reason than the shock at how long these Summaries can 
take.  =)

-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] Memory Allocator Part 2: Did I get it right?

[Brett C.]

Evan Jones wrote:
Sorry for taking so long to get back to this thread, it has been one of 
those weeks for me.

On Feb 16, 2005, at 2:50, Martin v. Löwis wrote:
Evan then understood the feature, and made it possible.

This is very true: it was a very useful exercise.
I can personally accept breaking the code that still relies on the
invalid APIs. The only problem is that it is really hard to determine
whether some code *does* violate the API usage.

Great. Please ignore the patch on SourceForge for a little while. I'll 
produce a "revision 3" this weekend, without the compatibility hack.

Evan uploaded the newest version (@ http://www.python.org/sf/1123430) and he 
says it is "complete".

Assuming a code review says the patch is sane, do we want to go with this 
garbage collection change?  From past discussions I don't remember a consensus 
on acceptance or rejection, just lots of discussion about ripping out the hacks 
to allow freeing memory w/o holding the GIL (I assume Evan's patch rips that 
code out).

-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] Requesting that a class be a new-style class

[Brett C.]

Guido van Rossum wrote:
This is something I've typed way too many times:
Py> class C():
  File "", line 1
class C():
^
SyntaxError: invalid syntax
It's the asymmetry with functions that gets to me - defining a
function with no arguments still requires parentheses in the
definition statement, but defining a class with no bases requires the
parentheses to be omitted.

It's fine to fix this in 2.5. I guess I can add this to my list of
early oopsies -- although to the very bottom. :-)
It's *not* fine to make C() mean C(object). (We already have enough
other ways to declaring new-style classes.)
OK, this is now in thanks to the following revisions:
Checking in Grammar/Grammar;
/cvsroot/python/python/dist/src/Grammar/Grammar,v  <--  Grammar
new revision: 1.53; previous revision: 1.52
done
Checking in Python/graminit.c;
/cvsroot/python/python/dist/src/Python/graminit.c,v  <--  graminit.c
new revision: 2.39; previous revision: 2.38
done
Checking in Python/compile.c;
/cvsroot/python/python/dist/src/Python/compile.c,v  <--  compile.c
new revision: 2.349; previous revision: 2.348
done
Checking in Misc/NEWS;
/cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
new revision: 1.1267; previous revision: 1.1266
done
-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] python-dev Summary for 2005-02-15 through 2005-02-28 [draft]

[Brett C.]

Decided to just plow through the next Summary so that I was finally caught up.
I am not expecting the candidates for taking of the Summaries to write stuff 
for this one (although I wouldn't mind it  =).  The idea of having them work 
together to write the Summaries has been proposed, but this is going out before 
I have heard back.

Depending on the number of people who send in edits, this could go out the same 
time as the 2005-02-01 Summary or I might wait until Monday night so people who 
only check mail on weekdays have a chance to look at this.

-
=
Summary Announcements
=

Status of the candidates

XXX
---
PyCon Looms
---
PyCon_ is coming!  Be there or be a Java or Perl coder!
.. _PyCon: http://www.pycon.org/
=
Summaries
=
-
PEP movements
-
`PEP 309`_ is now final since the 'functional' module has now been checked into 
Python.

.. _PEP 309: http://www.python.org/peps/pep-0309.html
Contributing threads:
  - `PEP 309 enhancements <>`__
  - `PEP 309 <>`__
--
Indices for slices other objects with __int__ not okay
--
Travis Oliphant asked if it would be possible to patch slicing so that any 
object that defines __int__ could be used.

Guido didn't like this idea, though.  Float, for instance, has __int__ defined. 
 Guido admitted he "unfortunately copied a design mistake from C here".  He 
said he might add a __trunc__ magic method in Python 3000 for objects that 
really can't be viewed as an int but are willing to have data loss to give one.

Contributing threads:
  - `Fixing _PyEval_SliceIndex so that integer-like objects can be used <>`__
  - `Fix _PyEval_SliceIndex (Take two) <>`__

Why can't ``class C(): pass`` be acceptable?

No reason.  =)  So as of Python 2.5 it is acceptable to have empty parentheses 
for class definitions.  It does create a classic class and not a new-style one.

Contributing threads:
  - `Requesting that a class be a new-style class <>`__
--
What basestring is truly meant for
--
What is basestring for?  According to Guido it is purely for unicode and str to 
inherit from to help with checks in code where either type is acceptable.  It 
is *not* meant to be used as a base class for any other classes.

Contributing threads:
  - `UserString <>`__
--
Quickly opening an SF bug/patch in Firefox/Thunderbird
--
Martin v. LÃwis posted a way to use the DictionarySearch_ plug-in for Mozilla 
to launch a browser with the highlighted patch/bug #.  See the email for the 
thread on how to get it to work.

.. _DictionarySearch: 
http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org/dictionarysearch/dictionarysearch_0.8.xpi

Contributing threads:
  - `Quick access to Python bug reports in Thunderbird <>`__

Optimizing ``x in [1, 2, 3]``

Raymond Hettinger has been trying to teach the peepholer some new tricks to 
optimize ``x in [1, 2, 3]`` and the like into a faster operation.  Initially he 
got it to change the list to a tuple.  He then tried turning the list into a 
frozenset, but that had the unforeseen issue of breaking semantics since it 
then required the object being checked for to be hashable.

So Raymond suggested introducing a SearchSet that tried the comparison as a 
frozenset first, and upon failure of hashing, to old way of just looking at 
each item in the list.

But this seemed like overkill since most lists would be small; probably usually 
under 4 items.  But Fredrik Lundh suggested expanding it to ``x == 1 or x == 2 
or x == 3``.  This seemed like a performance boost when the items of the list 
were lists since the COMPARE_OP opcode special-cases comparing ints.  But for 
other instances it probably isn't worth it unless more special-casing is done 
in the opcodes.

Contributing threads:
  - `Prospective Peephole Transformation <>`__
--
A DupStore opcode?
--
Raymond Hettinger suggested a new opcode called DupStore that would replace 
load;store opcode pairs.  Guido questioned if this was leading down a road of 
adding too much extra code for little benefit.

Off this a discussion about speeding up frame allocation, an area viewed as 
needing some optimization, started up.

Contributing threads:
  - `Store x Load x --> DupStore <>`__

===
Skipped Threads
===
+ pymalloc on 2.1.3
+ Exceptions *must*? be old-style classes?
+ subclassing PyCFunction_Type
+ Windows Low Fragementation Heap yields speedup of ~15%

Re: [Python-Dev] Failing tests: marshal, warnings

[Brett C.]

Greg Ward wrote:
Anyone else seeing test failures on the 2.4 branch right now?  I started
seeing this failure:
Both are passing for me on OS X 10.3.8 w/ a fresh cvs up as of 15:41 PT.  But I 
am getting failures for test_socket (ignoring the usual test__locale failure on 
OS X):

==
FAIL: testHostnameRes (__main__.GeneralModuleTests)
--
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 273, in testHostnameRes
self.fail("Error testing host resolution mechanisms.")
AssertionError: Error testing host resolution mechanisms.

Don't know if this is an "OS X" issue or a "my system" issue.
-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] Failing tests: marshal, warnings

[Brett C.]

Greg Ward wrote:
[SNIP]
A-ha!  I get it.  There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters.  This patch fixes both:
"""
--- Lib/test/test_descr.py  4 Mar 2005 04:47:04 -   1.202.2.2
+++ Lib/test/test_descr.py  7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
 def __init__(self):
 return 10
-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
 try:
-Foo()
-except RuntimeWarning:
 pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters
 def test_main():
"""
I'll check this in and merge to the trunk once I see all tests passing.
Well, I just checked in the list copy fix, so you only have to worry about 
adding the 'finally' clause to the 'try' statement.

-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] Failing tests: marshal, warnings

[Brett C.]

Brett C. wrote:
Greg Ward wrote:
[SNIP]
A-ha!  I get it.  There are two mistakes in test_descr.py:test_init():
lack of "finally" clause, and failure to make a copy of
warnings.filters.  This patch fixes both:
"""
--- Lib/test/test_descr.py  4 Mar 2005 04:47:04 -   1.202.2.2
+++ Lib/test/test_descr.py  7 Mar 2005 00:54:00 -
@@ -3973,15 +3973,18 @@
 def __init__(self):
 return 10
-oldfilters = warnings.filters
-warnings.filterwarnings("error", category=RuntimeWarning)
+oldfilters = warnings.filters[:]
 try:
-Foo()
-except RuntimeWarning:
 pass
-else:
-raise TestFailed, "did not test __init__() for None return"
-warnings.filters = oldfilters
+warnings.filterwarnings("error", category=RuntimeWarning)
+try:
+Foo()
+except RuntimeWarning:
+pass
+else:
+raise TestFailed, "did not test __init__() for None return"
+finally:
+warnings.filters = oldfilters
 def test_main():
"""
I'll check this in and merge to the trunk once I see all tests passing.
Well, I just checked in the list copy fix, so you only have to worry 
about adding the 'finally' clause to the 'try' statement.

nm, the commit failed because Greg beat me to the checkin by like a second.
-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] os.access and Unicode

[Brett C.]

Martin v. Löwis wrote:
Apparently, os.access was forgotten when the file system encoding
was introduced in Python 2.2, and then it was again forgotten in
PEP 277.
I've now fixed it in the trunk (posixmodule.c:2.334), and I wonder
whether this is a backport candidate. People who try to invoke
os.access with a non-ASCII filename on non-NT+ systems will get
a UnicodeError; with the patch, the operation will succeed
(assuming the characters are all supported in the file system
encoding).
Should this be backported?
If there was no other way to get os.access-like functionality, I would say it 
should be backported.  But since there are other ways to figure out everything 
that os.access can tell you I say don't backport and amend the docs to state it 
is not Unicode-aware.  If one was adventurous enough the docs could even 
include other ways to get the same info when Unicode had to be used.

-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] LinkedHashSet/LinkedHashMap equivalents

[Brett C.]

Steven Bethard wrote:
Delaney, Timothy C (Timothy) <[EMAIL PROTECTED]> wrote:
The perennial "how do I remove duplicates from a list" topic came up on
c.l.py and in the discussion I mentioned the java 1.5 LinkedHashSet and
LinkedHashMap. I'd thought about proposing these before, but couldn't
think of where to put them. It was pointed out that the obvious place
would be the collections module.
For those who don't know, LinkedHashSet and LinkedHashMap are simply
hashed sets and maps that iterate in the order that the keys were added
to the set/map. I almost invariably use them for the above scenario -
removing duplicates without changing order.
Does anyone else think it would be worthwhile adding these to
collections, or should I just make a cookbook entry?

I guess I'm -0 on this.
Though I was the one that suggested that collections is the right
place to put them, I'm not really certain how much we gain by
including them.  I too would only ever use them for removing
duplicates from a list.  But if we're trying to provide a solution to
this problem, I'd rather see an iterable-friendly one.  See a previous
thread on this issue[1] where I suggest something like:
def filterdups(iterable):
 seen = set()
 for item in iterable:
 if item not in seen:
 seen.add(item)
 yield item
Adding this to, say, itertools would cover all my use cases.  And as
long as you don't have too many duplicates, filterdups as above should
keep memory consumption down better.
I am -1 on adding LinkedHash*.  While I can understand wanting to get rid of 
duplicates easily and wanting a good solutoin, Steven's snippet of code shows 
rolling your own solution is easy.

Plus this can even be simplified down to a one-liner using itertools already::
  itertools.ifilterfalse(lambda item, _set=set():
   (item in _set) or (_set.add(item) and False),
 iterable)
I don't think it is the prettiest solution, but it does show that coming up 
with one is not hard nor restricted to only a single solution that requires 
knowing some Python idiom (well, mine does for the default arg to the lambda, 
but Steven's doesn't).

The last thing I want to happen is for Python's stdlib to grow every possible 
data structure out there like Java seems to have.  I don't ever want to have to 
think about what *variant* of a data structure I should use, only what *type* 
of data structure (and no, I don't count collections.deque and Queue.Queue an 
overlap since the latter is meant more for thread communication, at least in my 
mind).

-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] @deprecated (was: Useful thread project for 2.5?)

[Brett C.]

Stephan Richter wrote:
[SNIP - Michael's deprecated decorator]
This is a recipe for disaster. Creating a new function from the old can have 
unwanted side effects, since you effectively change the object. For example, 
if someone is monkey patching this function, then the deprecation warning 
gets lost. 

That's the idiom for decorators.  They will almost always be wrappers for other 
functions by returning a new function that uses closures to access the 
original.  Besides, you no longer have the original function directly available 
in the global namespace of the module since the name of the decorated function 
gets rebound before you have a chance to see the original function.  So there 
really is no issue with the function not being the exact same since you can't 
really see it undecorated without a lot of effort; no real change of the object 
that the user can ever tell.

And as for monkey-patching breaking something, that's there fault for 
monkey-patching.  Python doesn't prevent you from doing something stupid which 
why it is the language four out of five adults choose to code in (the fifth 
one, the hold-out, just can't let go of Java because he/she is a recent college 
grad and it is all they have ever known; they also think that EAFP is "evil"  =).

-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] Adding any() and all()

[Brett C.]

Jim Jewett wrote:
Guido van Rossum:

Whether to segregate these into a separate module: they are really a
very small amount of syntactic sugat, and I expect that in most cases,
instead of importing that module (which totally makes me lose my
context while editing) I would probably just write the extra line that
it takes to get the same effect with an explicit for loop and if
statement.

Is that so bad?
If you plan to use them often, then
from itertools import any, every
is reasonable.  If you only use them once and weren't expecting it
(and want your imports at the top) ... well how awful is it to have 
an extra line or two in your code?

Basically the question (at least in my mind) when it comes to built-ins is 
whether the usage is so basic and fundamental that sticking them in a module is 
done more for rigid organization than for convenience.  Personally, I think 
any() and all() meet this requirement.  With their ties to basic boolean 
testing they should be built into the language and not just a part of the 
stdlib.  If I am banging something out at a interpreter prompt I will want 
these functions easily accessible and I won't think of them as something to 
import.  This probably comes off as wishy-washy, but it is just what my mind is 
spitting out at the moment.

They also have the feeling as something that could be useful as a syntax 
(although I am just suggesting syntactic support!).  Which could be an even 
better way to measure whether something should be a built-in.  Would the 
function be useful as a syntactic addition to the language, but just can't 
quite reach the need of a new keyword?  Once again any() and all() feel like 
that to me.

These aren't *really* replacing map/filter/reduce because you're
adding the new functions now, but the old-function removal is 
waiting until (forever?)

Even if Python 3000 comes out a while from now, why wait?  Two more is not that 
much.  Besides, it isn't like we are adding functions as some crazy rate.  And 
Guido has stated that the 2.x branch stops once 2.9 (if it goes that long) 
comes out.  So at worst you only have to worry about 5 more releases to worry.  =)

-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] (no subject)

[Brett C.]

Phillip J. Eby wrote:
[SNIP]
One solution is to have a __signature__ attribute that's purely 
documentary.  That is, modifying it wouldn't change the function's 
actual behavior, so it could be copied with update_meta() but then 
modified by the decorator if need be.  __signature__ would basically be 
a structure like the one returned by inspect.getargspec().  Also, 
'instancemethod' would have a __signature__ equal to its 
im_func.__signature__ with the first argument dropped off, thus making 
it easy to introspect wrapper chains.

I discussed this approach with Guido in private e-mail a few months back 
during discussion about an article I was writing for DDJ about 
decorators.  We also discussed something very similar to 
'update_meta()', but never settled on a name.  Originally he wanted me 
to PEP the whole thing, but he wanted it to include optional type 
declaration info, so you can probably see why I haven't done anything on 
that yet.  :)

However, if we can define a __signature__ format that allows for type 
declaration, I imagine there'd be little problem with moving forward on it.

It could be as simple as just a bunch of tuples.  The following (assuming *args 
and **kwargs are not typed; don't remember if they can be)::

  def foo(pos1, pos2:int, key1="hi", key2=42:int, *args, **kwargs): pass
could be::
  ((('pos1', None), ('pos2', int)), (('key1', "hi", None), ('key2', 42, int)),
   'args', 'kwargs')
In case the format is not obvious, just a bunch of tuples grouped based on 
whether they are positional, keyword, or one of the collecting arguments.  For 
positional arguments, have a two-item tuple consisting of the argument name and 
the possible type.  For keyword, 3-item tuple with name, default value, and 
possible type.  Lacking *args and/or **kwargs could just be set to None for 
those tuple positions.

Since this is mainly for introspection tools the format can stand to be verbose 
and not the easiest thing to read by eye, but it must contain all possible info 
on the arguments.  And if actual execution does not use this slot, as Phillip 
is suggesting, but it is only for informative purposes we could make it 
optional.  It could also be set it to a descriptor that dynamically creates the 
tuple when called based on the function passed into the descriptor at creation 
time.  This could be rolled into the update_meta (or whatever it ends up being 
called) function.

-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] Rationale for sum()'s design?

[Brett C.]

Nick Coghlan wrote:
Guido van Rossum wrote:
On Tue, 15 Mar 2005 00:05:32 +1000, Nick Coghlan 
<[EMAIL PROTECTED]> wrote:

...   try:
... value += first
...   except TypeError:
... raise TypeError("Cannot add first element %r to initial value 
%r" % (first, value))

No, no, no! NO! Never catch a general exception like that and replace
it with one of your own. That can cause hours of debugging pain later
on when the type error is deep down in the bowels of the += operation
(or perhaps deep down inside something *it* invoked).

Ouch. Obviously, I hadn't thought about that. . .
Wasn't there a concept floating around some time ago to support 
exception chaining, so additional context information could be added to 
a thrown exception, without losing the location of the original problem?

Yes, but it didn't go anywhere.  See 
http://www.python.org/dev/summary/2003-06-01_2003-06-30.html#pep-317 for the 
summary.

-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] comprehension abbreviation (was: Adding any() and all())

[Brett C.]

Eric Nieuwland wrote:
Martin v. Löwis wrote:
That's not the full syntax. The full syntax is
[  for  in   ]
where
 can be an arbitrary expression: and, or, lambda, +, -, ...
 can be a list of expression, except for boolean and
relational expressions (but I think this is further constrained
semantically)
 list a list of tests
 is optional, and can be another for or if block

Aren't these names a bit mixed up w.r.t. what's in that position?
The names come directly from the grammar file (Grammar/Grammar) and thus have 
multiple uses.  Basically ignore the actual names and just consider them 
placeholders.

-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] python-dev Summary for 2005-03-01 through 2005-03-15 [draft]

[Brett C.]

Amazingly on time thanks to the quarter being over.  You can't see me jumping 
up and down in joy over that fact, but I am while trying not to hit the ceiling 
as I do it (for those of you who have never met me, I'm 6'6" tall, so jumping 
in a room is not always the smartest thing for me, especially when ceiling fans 
are involved).

Since I will be on a plane most of tomorrow heading to DC for PyCon I won't get 
to this any sooner than Saturday while I am at the sprints.  Might send it out 
Saturday or Sunday during a lull in the sprint, so please get corrections and 
additions in by then.

--
=
Summary Announcements
=
-
Second to last summary for me
-
Just a reminder, after this Summary there is only one more left for me to 
write.  After that Tim Lesher, Tony Meyer, and Steven Bethard will be taking over.

-
See you at PyCon!
-
PyCon_ is practically upon us!  If you are going to be there, great!  Please 
feel free to say hello if you run into me (will be at the sprints and the 
conference Wednesday and Thursday; skipping Friday to see a friend).  Always 
happy to stop-and-chat.

.. _PyCon: http://www.pycon.org/

2.4.1 should be out soon

Python 2.4.1c1 is out.  Very shortly c2 will be released.  Assuming no major 
issues come up, 2.4 final will be out.

But in order to make sure no issues come up, we need the code to be tested! 
Please get the code and run the regression tests.  If you are on a UNIX system 
it is as easy as running ``make test`` (``make testall`` is even better).  The 
tests can also be run on non-UNIX systems; see 
http://docs.python.org/lib/regrtest.html on how.

=
Summaries
=
--
2.4 should be out soon
--
Python 2.4.1c1 was releaseed, but enough bugs were found and subsequently fixed 
that c2 release will occur before 2.4 final comes out.

Contributing threads:
  - `2.4.1c1 March 10th, 2.4.1 March 17th <>`__
  - `Failing tests: marshal, warnings <>`__
  - `BRANCH FREEZE for 2.4.1rc1,  UTC, 2005-03-10 <>`__
  - `branch release24-maint is unfrozen, 2.4.1rc2? <>`__
  - `os.access and Unicode <>`__
  - `RELEASED Python 2.4.1, release candidate 1 <>`__
  - `distutils fix for building Zope against Python 2.4.1c1 <>`__
  - `Python2.4.1c1 and win32com <>`__
  - `Open issues for 2.4.1 <>`__
---
Getting state of all threads in interpreter
---
Florent Guillaume wrote some code for Zope that returned the current state of 
all threads in the interpreter, regardless of whether they were hung or not. 
Tim Peters suggested someone write up some code so that this could be made 
available in Python itself.

Contributing threads:
  - `Useful thread project for 2.5? <>`__
-
No new features in micro releases
-
A bug in os.access() not allowing Unicode strings triggered the discussion of 
whether it was a bugfix to repair the issue or a new feature.  In the end it 
was decided it was a bugfix.  But the point was specified that micro releases 
should never have any new feature, no matter how small.

Contributing threads:
  - `[Python-checkins] python/dist/src/Modules  ossaudiodev.c, 1.35, 1.36 <>`__
  - `No new features <>`__
  - `os.access and Unicode <>`__
  - `rationale for the no-new-features approach <>`__
-
Python wins Jolt "Productivity Award"
-
Python was runner-up in the `15th annual Jolt Awards`_ in the category of 
"Languages and Development Environments", being given the "Productivity Award". 
 Python is now award-winning.  =)

.. _15th annual Jolt Awards: 
http://www.sdmagazine.com/jolts/15th_jolt_finalists.html

Contributing threads:
  - `FWD: SD MAgazine.com - Jolt Awards Winners <>`__
  - `Python 2.4 won the "Jolt productivity award" last night <>`__
--
New built-ins: any() and all()
--
Python 2.5 gains two new built-ins: any(), which returns True if the iterable 
passed to it contains any true items, and all(), which returns True if all the 
items in the iterable passed to it are true.

Contributing threads:
  - `Adding any() and all() <>`__

Abbreviating list comprehensions

The idea of allowing list comprehensions when the item being appended to the 
new list is passed directly in was proposed: ``[x in seq if f(x)`` would be 
equivalent to ``[x for x in seq if f(x)]``.

The debate on this one is still going, but my gut says it won't be accepted; 
TOOWTDI and all.

Contributing threads:
  - `Adding any() and all() <>`__
  - `comprehension abbreviation <>`__
-
sum() sema

Re: [Python-Dev] [AST] Procedure for AST Branch patches

[Brett C.]

Nick Coghlan wrote:
What's the current situation with providing fixes for AST branch problems?
Make sure "AST" is used in the subject line; e.g., "[AST]" at the beginning. 
Unfortunately the AST group is only available for patches; not listed for bug 
reports (don't know why; can this be fixed?).

Other than that, just assign it to me since I will most likely be doing AST 
work in the near future.

-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] [AST] Procedure for AST Branch patches

[Brett C.]

Grant Olson wrote:
 


Make sure "AST" is used in the subject line; e.g., "[AST]" at 
the beginning. 
Unfortunately the AST group is only available for patches; 
not listed for bug reports (don't know why; can this be fixed?).

Other than that, just assign it to me since I will most 
likely be doing AST work in the near future.


Brett,
I sent a few outstanding ones your way.  I hate to complain again, I know
everyone involved are volunteers, etc, etc; but it'd be really nice if
someone could take a look at '[ 742621 ] ast-branch: msvc project sync'.
The patch is almost two years old now, has been updated for VC7.1 and still
hasn't been checked in.  Without this, any Windows developers who check out
the ast-branch will experience a broken build.
The problem is that I don't have access to a Windows machine so there is no way 
to verify the patch myself.  I will try to get someone here to verify the 
patch, but I am not comfortable doing a blind commit.  If one other person 
could verify that the patch is good I will apply it.

-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] docstring before function declaration

[Brett C.]

Nicholas Jacobson wrote:
IIRC, Guido once mentioned that he regretted not
setting function docstrings to come before the
function declaration line, instead of after.
He did, but I don't know how strong that regret is.
i.e.
"""This describes class Bar."""
class Bar:
...
Or with a decorator:
"""This describes class Bar."""
@classmethod
class Bar:
...
Versus the current method:
class Bar:
"""This describes class Bar."""
def foo:
...
I am going to be -42 on this one.  I personally love having the docstring below 
the definition line.  So much so, in fact, that in personal C code I use the 
same style for documentation.  I find it easier to browse the source since 
where a definition starts is much cleaner (yes, syntax highlighting and 
searching for ``\s*def `` works as well, but I am thinking when you are just 
scrolling).

Beyond that I can't really rationalize it beyond just aesthetics at the moment. 
 But I definitely prefer the current style.

-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] [AST] question about marshal_write_*() fxns

[Brett C.]

For those of you who don't know, I am sprinting on the AST branch here on 
PyCon.  Specifically, I am fleshing out Python/compile.txt so that it can act 
as a good intro to new users and as a design doc.

But one of things I am not sure of is what the marshal_write_*() functions in 
Python/Python-ast.c are used for.  I assume they output to the marshal format, 
but there is mention of a byte stream format and so I thought it might be that 
as well.

Anyone know which one it is?
-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] [AST] question about marshal_write_*() fxns

[Brett C.]

Neil Schemenauer wrote:
On Mon, Mar 21, 2005 at 11:53:04AM -0500, Brett C. wrote:
But one of things I am not sure of is what the marshal_write_*() functions 
in Python/Python-ast.c are used for.  I assume they output to the marshal 
format, but there is mention of a byte stream format and so I thought it 
might be that as well.

I believe the idea is that they can be used to move an AST back and
forth between Python "space" (e.g. you could build an AST using
Python code and then marshal it and send it to the C compiler).
Jeremy emailed me and said the same thing.  Name should be changed, though, to 
prevent this confusion.  Jeremy thought maybe the name should be changed.  Here 
are some ideas for a different name (thinking in terms of what the name would 
be changed to for the prefix of the function names):

- byte_encode
- linear_form
- zephyr_encoding
- flat_form
- flat_prefix
- prefix_form
- scheme_form  =)
For those that don't know and it wasn't obvious from the names, the format is a 
prefix-based, linear form.

-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] [AST] Procedure for AST Branch patches

[Brett C.]

Grant Olson wrote:
 


Make sure "AST" is used in the subject line; e.g., "[AST]" at 
the beginning. 
Unfortunately the AST group is only available for patches; 
not listed for bug reports (don't know why; can this be fixed?).

Other than that, just assign it to me since I will most 
likely be doing AST work in the near future.


Brett,
I sent a few outstanding ones your way.  I hate to complain again, I know
everyone involved are volunteers, etc, etc; but it'd be really nice if
someone could take a look at '[ 742621 ] ast-branch: msvc project sync'.
The patch is almost two years old now, has been updated for VC7.1 and still
hasn't been checked in.  Without this, any Windows developers who check out
the ast-branch will experience a broken build.
OK, thanks to John Ehresman here at PyCon sprint I got logistix's patch 
applied.  Beyond a warning that a warning that decode_unicode() is never called 
and the parser module failing to compile under Windows everything should be 
fine for compiling the AST branch.

Passing the test suite, though, is another question.  =)
-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] [AST] Procedure for AST Branch patches

[Brett C.]

Nick Coghlan wrote:
> Brett C. wrote:
> 
>> OK, thanks to John Ehresman here at PyCon sprint I got logistix's
>> patch applied.  Beyond a warning that a warning that decode_unicode()
>> is never called and the parser module failing to compile under Windows
>> everything should be fine for compiling the AST branch.
> 
> 
> Under Linux (Suse 9.1), the parser module compiles with a couple of
> warnings about implicit declaration of PyParser_SimpleParseString, but
> the .so fails to load due to a missing symbol PyNode_Compile.
> 

It's a known issue.  I am just ignoring the failed compile.

>> Passing the test suite, though, is another question.  =)
> 
> 
> Heh. I managed to get test_grammar to pass 100% last night, which is at
> least a start!
> 

Yeah, I am hoping to look at your generators patch before you get back in the
country.

> And I must say that the new system is rather nice to work with - it took
> me a while to work out what was going on, but the multi-pass 'build
> AST', 'build symbol table', 'compile AST' is much cleaner than it is
> with the lists-of-lists arrangement on the trunk (which is the entire
> point of the AST-branch, I guess. . .)
> 

How the system works will be *much* clearer with the new version of
Python/compile.txt, assuming everyone has not been lying to me about the 
clarity.

-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] Deprecating 2.2 old bugs

[Brett C.]

Facundo Batista wrote:
> Going on with the old bugs checking, here are the results for 2.2.
> When I'll finish this will be put in an informational PEP.
> 

I just want to publicly thank Facundo for doing this.  I remember when I went
through one weekend and did a ton of old bug reports; it ain't exactly fun.
And he even spent his PyCon sprint time on this some more.  So thanks from me
for putting the time in on this.

-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] python-dev Summary for 2005-03-16 through 2005-03-31 [draft]

[Brett C.]

OK, so here is my final Summary.  Like to send it out some time this weekend so
please get corrections in ASAP.



=
Summary Announcements
=

---
My last summary
---
So, after nearly 2.5 years, this is my final python-dev Summary.  Steve
Bethard, Tim Lesher, and Tony Meyer will be taking over for me starting with
the April 1 - April 15 summary (and no, this is not an elaborate April Fool's).
 I have learned a ton during my time doing the Summaries and I appreciate
python-dev allowing me to do them all this time.  Hopefully I will be able to
contribute more now in a programming capacity thanks to having more free time.


PyCon was fantastic!

For those of you who missed PyCon, you missed a great one!  It is actually my
favorite PyCon to date.  Already looking forward to next year.


Python fireside chat

Scott David Daniels requested a short little blurb from me expounding on my
thoughts on Python.  Not one to pass on an opportunity to just open myself and
possibly shoot myself in the foot, I figured I would take up the idea.  So hear
we go.

First, I suspect Python 3000 stuff will start to make its way into Python.
Stuff that doesn't break backwards compatibility will most likely start to be
implemented as we head toward the Python 2.9 barrier (Guido has stated several
times that there will never be a Python 2.10).  Things that are not
backwards-compatible will most likely end up being hashed out in various PEPs.
 All of this will allow the features in Python 3000 to be worked in over time
so there is not a huge culture shock.

As for things behind the scenes, work on the back-end will move forward.  Guido
himself has suggested that JIT work should be looked into (according to an
interview at http://www.devsource.com/article2/0,1759,1778272,00.asp).  I know
I plan to fiddle with the back-end to see if the compiler can be made to do
more work.

Otherwise I expect changes to be made, flame wars to come and go, and for
someone else to write the python-dev Summaries.  =)


=
Summaries
=


Python 2.4.1 out

Anthony Baxter, on behalf of python-dev, has released `Python 2.4.1`_.

.. _Python 2.4.1: http://www.python.org/2.4.1/

Contributing threads:
  - `RELEASED Python 2.4.1, release candidate 1
`__
  - `RELEASED Python 2.4.1, release candidate 2
`__
  - `BRANCH FREEZE for 2.4.1 final, 2005-03-30 00:00 UTC
`__
  - `RELEASED Python 2.4.1 (final)
`__


-
AST branch update
-
I, along with some other people, sprinted on the AST branch at PyCon.  This led
to a much more fleshed out design document (found in Python/compile.txt in the
AST branch), the ability to build on Windows, and applying Nick Coghlan's fix
for hex numbers.

Nick also did some more patch work and asked how AST work should be tagged.
There is now an AST category on SourceForge that people should use to flag
things as for the AST.  They should also, by default, assign such items to me
("bcannon" on SF).  We have also taken to flagging threads on the AST with
"[AST]" as the first item in the subject line.

There was also a slight discussion/clarification on the functions named
marshal_write_*() that output a byte format for the AST that is supposed to be
agnostic of implementation.  This will most likely end up being used as the way
to pass AST objects back and forth between C and Python code.  But with the
name collision of the word "marshal" with the actual 'marshal' module, it needs
to be changed.  I have suggested

- byte_encode
- linear_form
- zephyr_encoding
- flat_form
- flat_prefix
- prefix_form

while Nick Coghlan suggsted

- linear_ast
- bytestream_ast

Obviously I prefer "form" and Nick prefers "ast".  With Nick's reply being
independent of mine it will most likely have "linear" or "byte" in the name.

With the patches for descriptors and generator expressions sitting on SF,
syntactic support for all of Python 2.4 should get applied shortly.  After that
it will come down to bug hunting and such.  There is a todo list in the design
doc for those interested in helping out.

Contributing threads:
  - `Procedure for AST Branch patches
`__
  - `[AST] A somewhat less trivial patch than the last one. . .
`__
  - `[AST] question about marshal_write_*() fxns
`__


---
Putting docst

Re: [Python-Dev] Re: python-dev Summary for 2005-03-16 through 2005-03-31[draft]

[Brett C.]

Terry Reedy wrote:
>>This led to a much more fleshed out design document
>>(found in Python/compile.txt in the AST branch),
> 
> 
> The directory URL
> 
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/?only_with_tag=ast-branch
> 
> or even the file URL
> 
> http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Python/Attic/compile.txt?rev=1.1.2.10&only_with_tag=ast-branch&view=auto
> 
> would be helpful to people not fully familiar with the depository and the 
> required prefix to 'Python' (versus 'python').  I initially found the 
> two-year-old
> 
> ttp://cvs.sourceforge.net/viewcvs.py/python/python/nondist/sandbox/ast/
> 

Yeah, that has become a popular suggestion.  It has been fixed.  Just didn't
think about it.  One of those instances where I have been neck-deep in
python-dev for so long I forgot that not everyone has a CVS checkout.  =)

> 
> 
>>The idea of moving docstrings after a 'def' was proposed
> 
> 
> /after/before/
> 

Fixed.

Thanks, Terry.

-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] inconsistency when swapping obj.__dict__ with a dict-like object...

[Brett C.]

Alex A. Naanou wrote:
> Hi!
> 
> here is a simple piece of code
> 
> ---cut---
> class Dict(dict):
> def __init__(self, dct={}):
> self._dict = dct
> def __getitem__(self, name):
> return self._dct[name]
> def __setitem__(self, name, value):
> self._dct[name] = value
> def __delitem__(self, name):
> del self._dct[name]
> def __contains__(self, name):
> return name in self._dct
> def __iter__(self):
> return iter(self._dct)
> 
> class A(object):
> def __new__(cls, *p, **n):
> o = object.__new__(cls)
> o.__dict__ = Dict()
> return o
> 
> a = A()
> a.xxx = 123
> print a.__dict__._dict
> a.__dict__._dict['yyy'] = 321
> print a.yyy
> 
> --uncut--
> 
> 
> Here there are two problems, the first is minor, and it is that
> anything assigned to the __dict__ attribute is checked to be a
> descendant of the dict class (mixing this in does not seem to work)...
> and the second problem is a real annoyance, it is that the mapping
> protocol supported by the Dict object in the example above is not used
> by the attribute access mechanics (the same thing that once happened
> in exec)...
> 

Actually, overriding __getattribute__() does work; __getattr__() and
__getitem__() doesn't.  This was brought up last month at some point without
any resolve (I think Steve Bethard pointed it out).

> P.S. (IMHO) the type check here is not that necessary (at least in its
> current state), as what we need to assert is not the relation to the
> dict class but the support of the mapping protocol
> 

Semantically necessary, no.  But simplicity- and performance-wise, maybe.  If
you grep around in Objects/classobject.c, for instance, you will see
PyClassObject.cl_dict is accessed using PyDict_GetItem() and I spotted at least
one use of PyDict_DelItem().  To use the mapping protocol would require
changing all of these to PyObject_GetItem() and such.

Which will be a performance penalty compared to PyDict_GetItem().  So the
question is whether the flexibility is worth it.

-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] Unified or context diffs?

[Brett C.]

Nick Coghlan wrote:
> Are context diffs still favoured for patches?
> 
> The patch submission guidelines [1] still say that, but is it actually
> true these days? I personally prefer unified diffs, but have been
> generating context diffs because of what the guidelines say.
> 

I personally like unified diffs a lot more since you can see exactly how a line
changed compared to the previous version, but that's me.  I just checked the
dev FAQ and it consistently says contextual diffs as well.

> Brett can probably guess why I'm asking :)
> 

=)

> Cheers,
> Nick.
> 
> [1] http://www.python.org/patches/
> 

I didn't even know that page existed!

I thought at one point this question came up and the general consensus was that
unified diffs were preferred?

-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] Unified or context diffs?

[Brett C.]

Barry Warsaw wrote:
> On Wed, 2005-04-13 at 15:54, Brett C. wrote:
> 
> 
>>I thought at one point this question came up and the general consensus was 
>>that
>>unified diffs were preferred?
> 
> 
> Back in the day, we preferred context diffs, and I think of the original
> Python core group, Guido was the last holdout.  But IIRC, a few years
> ago the issue came up again; Guido had changed his mind so we changed
> syncmail to produce unified diffs.
> 

Eh.  Guido doesn't deal with patches anymore, so his opinion doesn't count.  =)

> IMO unifieds are preferred when the diffs are for human consumption, but
> when they're only for machine consumption, anything that the patch
> program accepts is fine.
> 

OK, it seems like everyone who cares enough to speak up has said so far that
unified diffs are better I will change the docs some time between now and when
I keel over dead to have people use unified diffs assuming some rush of people
don't suddenly start saying they prefer contextual diffs.

-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] shadow password module (spwd) is never built due to error in setup.py

[Brett C.]

Irmen de Jong wrote:
> Martin v. Löwis wrote:
> 
>> Irmen de Jong wrote:
>>
>>> Please advise?
>>
>>
>>
>> setup.py should refer to config_h_vars, which in turn should be set
>> earlier.
>>
>> Regards,
>> Martin
> 
> 
> Ah so the setup.py script is flawed.
> However, the sysconfig object doesn't contain a config_h_vars...
> So I guess distutils must be patched too?
> 

While it probably should be included in distutils.sysconfig, config_h_vars was
created later on in setup.py by some code dealing with whether to compile
expat.  I just moved that up to the top of the funciton so that it can be used
sooner.

Fixed in rev. 1.217 .  Sorry about the bad checking that broke the building of
it in the first place.  =)

-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-dev Summary for 2005-04-01 through 2005-04-15 [draft]

[Brett C.]

Tim Lesher wrote:
> Here's the first draft of the python-dev summary for the first half of
> April.  Please send any corrections or suggestions to the summarizers.
> 
> ==
> Summary Announcements
> ==
> 
> ---
> New python-dev summary team
> ---
> 
> This summary marks the first by the team of Steve Bethard, Tim Lesher,
> and Tony Meyer.  We're trying a collaborative approach to the
> summaries: each fortnight, we'll be getting together in a virtual
> smoke-filled back room to divide up the interesting threads.  Then
> we'll stitch together the summaries in roughly the same form as you've
> seen in the past. We'll mark each editor's entries with his initials.
> 

Woohoo!  Once again, thanks for doing this guys.

> Thanks to Brett Cannon for sixty-one excellent python-dev summaries.
> Also, thanks for providing scripts to help get the new summaries off
> the ground! We're looking forward to the contributions you'll make to
> the Python core, now that the summaries aren't taking up all your
> time.
> 

Gee, no pressure.  =)

[SNIP]
> ---
> Security capabilities in Python
> ---
> 
> The issue of security came up again, and Ka-Ping Yee suggested that in
> Python's restricted execution mode secure proxies can be created by
> using lexical scoping.  He posted `some code`_ for revealing only
> certain "facets" of an object by using a function to declare a proxy
> class that used function local variables to build the proxy. Thus to

"... that used a function's local variables ..."

[SNIP]
> 
> -
> Improving GilState API Robustness
> -
> 
> Michael Hudson noted that his changes to thread handling in the
> readline module appeared to trigger `bug 1176893`_ ("Readline
> segfault"). However, he believed the problem lay in the GilState API,
> rather than in his changes: PyGilState_Release crashes if
> PyEval_InitThreads wasn't called, even if the code you're writing
> doesn't use multiple threads.
> 
> He proposed several solutions, none of which met with resounding
> approbation, and Tim Peters noted that `PEP 311`_, Simplified Global
> Interpreter Lock Acquisition for Extensions, "specifically disowns
> responsibility for worrying about whether Py_Initialize and
> PyEval_InitThreads have been called."
> 
> Bob Ippolito wondered whether just calling PyEval_InitThreads directly
> in Py_Initialize might be a better idea.  No objections were raised,
> so long as the underlying OS locking mechanisms weren't overly
> expensive; some initial benchmarks indicated that this approach was
> viable, at least on Linux and OS X.
> 
> Contributing threads:
> 
> - `threading (GilState) question
> `__
> 
> .. _bug 1176893:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1176893&group_id=5470&atid=105470
> 

For any tracker item, the easiest way to do a URL is to use the python.org
shortcut: http://www.python.org/sf/# .  So the above would be
http://www.python.org/sf/1176893 .

> .. _PEP 311: http://www.python.org/peps/pep-0311.html
> 
> [TDL]
> 
> 
> Unicode byte order mark decoding
> 
> 
> Evan Jones saw that the UTF-16 decoder discards the byte-order mark
> (BOM) from Unicode files, while the UTF-8 decoder doesn't. Although
> the BOM isn't really required in UTF-8 files, many Unicode-generating
> applications, especially on Microsoft platforms, add it.
> 
> Walter Dörwald created a patch_ to add a UTF-8-Sig codec that generates
> a BOM on writing and skips it on reading, but after a long discussion
> on the history of the Unicode, Microsoft's influence over its

"... of Unicode and Microsoft's influence ..."

[SNIP]
> ---
> Developers List
> ---
> 
> Raymond Hettinger has started a `project to track developers`_ and the
> (tracker and commit) privileges they have, and who gave them the privileges,
> and why (for example, was it for a one-shot project). Removing inactive
> developers should improve clarity, institutional memory, security, and makes
> everything tidier.  Raymond has begun contacting recently inactive
> developers to check whether they still require the privileges they have.
> 
> Contributing threads:
> 
>  - `Developer list update
> `__
> 
> .. _project to track developers:
> http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Misc/developers.txt
> 
> [TAM]
> 
> 
> Marshalling Infinity
> 
> 
> Scott David Daniels kicked off a very long thread by asking what (un)marshal
> should do with floating point NaNs.  The current behaviour (as with any NaN,
> infinity, or signed zero) is undefined: a platform-depen

[Python-Dev] Proper place to put extra args for building

[Brett C.]

I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
AST branch.  I thought that OPT was the proper variable to put stuff like this
into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
-Wstrict-prototypes``.  Obviously I could just tack all of that into my own
thing, but that seems like an unneeded step.

>From looking at Makefile.pre.in it seems like CFLAGSFORSHARED is meant for
extra arguments to the compiler.  Is that right?

And I will document this in Misc/Specialbuilds.txt to fix my initial blunderous
checkin of specifying OPT (or at least clarifying it).

-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] Proper place to put extra args for building

[Brett C.]

Martin v. LÃwis wrote:
> Brett C. wrote:
> 
>>I am currently adding some code for a Py_COMPILER_DEBUG build for use on the
>>AST branch.  I thought that OPT was the proper variable to put stuff like this
>>into for building (``-DPy_COMPILER_DEBUG``), but that erases ``-g -Wall
>>-Wstrict-prototypes``.  Obviously I could just tack all of that into my own
>>thing, but that seems like an unneeded step.
> 
> 
> Actually, this step is needed.
> 

Damn.  OK.

[SNIP]
> It might be reasonable to add a variable that will just take additional
> compiler flags, and never be modified in configure.

The other option is to not make configure.in skip injecting arguments when a
pydebug build is done based on whether OPT is defined in the environment.  So
configure.in:670 could change to ``OPT="$OPT -g -Wall -Wstrict-prototypes"``.

The line for a non-debug build could stay as-is since if people are bothering
to tweak those settings for a normal build they are going out of there way to
tweak settings.  Seems like special-casing this for pydebug builds makes sense
since the default values will almost always be desired for a pydebug build.
And those rare cases you don't want them you could just edit the generated
Makefile by hand.  Besides it just makes our lives easier and the special
builds even more usual since it is one less thing to have to tweak.

Sound reasonable?

-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] Proper place to put extra args for building

[Brett C.]

Martin v. LÃwis wrote:
> Brett C. wrote:
> 
>>The other option is to not make configure.in skip injecting arguments when a
>>pydebug build is done based on whether OPT is defined in the environment.  So
>>configure.in:670 could change to ``OPT="$OPT -g -Wall -Wstrict-prototypes"``.
> 
> 
> That's a procedural question: do we want to accept environment settings
> only when running configure, or do we also want to honor environment or
> make command line settings when make is invoked. IOW, it is ok if
> 
> export OPT=-O6
> ./configure
> make
> 
> works. But what about
> 
> ./configure
> export OPT=-O6
> make
> 
> or
> 
> ./configure
> make OPT=-O6
> 
> All three can be only supported for environment variables that are never
> explicitly set in Makefile, be it explicitly in Makefile.pre.in, or
> implicitly through configure.
> 

Hmm.  OK, that is an interesting idea.  Would make rebuilding a lot easier if
it was just an environment variable that was part of the default OPT value;
``OPT="$BUILDFLAGS -g -Wall -Wstrict-prototyping".

I say we go with that.  What is a good name, though?  PY_OPT?

> 
>>The line for a non-debug build could stay as-is since if people are bothering
>>to tweak those settings for a normal build they are going out of there way to
>>tweak settings.  Seems like special-casing this for pydebug builds makes sense
>>since the default values will almost always be desired for a pydebug build.
>>And those rare cases you don't want them you could just edit the generated
>>Makefile by hand.  Besides it just makes our lives easier and the special
>>builds even more usual since it is one less thing to have to tweak.
>>
>>Sound reasonable?
> 
> 
> No. I thought you were talking about extra args, such as -fbrett-cannon.

I am, specifically ``-DPy_COMPILER_DEBUG`` to be tacked on as a flag to gcc.

> But now you seem to be talking about arguments that replace the ones
> that configure comes up with. Either of these might be reasonable, but
> they require different treatment. Replacing configure results is
> possible already

I am only talking about that because that is how OPT is currently structured;
configure.in replaces the defaults with what the user provides if the
environment variable is set.  This is what I don't want.
___
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] Reference counting when entering and exiting scopes

[Brett C.]

Matthew F. Barnes wrote:
> Someone on python-help suggested that I forward this question to
> python-dev.
> 
> I've been studying Python's core compiler and bytecode interpreter as a
> model for my own interpreted language,

Might want to take a peek at the AST branch in CVS; that is what the compiler
is going to change to as soon as it is complete.

> and I've come across what appears
> to be a reference counting problem in the `symtable_exit_scope' function
> in .
> 
> At this point I assume that I'm just misunderstanding what's going on.  So
> I was hoping to contact one of the core developers before I go filing what
> could very well be a spurious bug report against Python's core.
> 

Spurious bug reports are fine.  If they turn out to be that they get closed as
such.  Either way time is spent checking it whether it goes there or here.  But
at least with a bug report it can be tracked more easily.

So for future reference, just go ahead and file the bug report.

> Here's the function copied from CVS HEAD:
> 
> static int
> symtable_exit_scope(struct symtable *st)
> {
>   int end;
> 
>   if (st->st_pass == 1)
>   symtable_update_free_vars(st);
>   Py_DECREF(st->st_cur);
>   end = PyList_GET_SIZE(st->st_stack) - 1;
>   st->st_cur = (PySymtableEntryObject *)PyList_GET_ITEM(st->st_stack,
> end);
>   if (PySequence_DelItem(st->st_stack, end) < 0)
>   return -1;
>   return 0;
> }
> 
> My issue is with the use of PyList_GET_ITEM to fetch a new value for the
> current scope.  As I understand it, PyList_GET_ITEM does not increment the
> reference count for the returned value.  So in effect we're borrowing the
> reference to the symtable entry object from the tail of the scope stack. 
> But then we turn around and delete the object from the tail of the scope
> stack, which DOES decrement the reference count.
> 
> So `symtable_exit_scope' has a net effect of decrementing the reference
> count of the new current symtable entry object, when it seems to me like
> it should stay the same.  Shouldn't the reference count be incremented
> when we assign to "st->st_cur" (either explicitly or by fetching the
> object using the PySequence API instead of PyList)?
> 
> Can someone explain the rationale here?
> 

If you look at how symtable_enter_scope() and symtable_exit_scope() work
together you will notice there is actually no leak.  symtable_enter_scope()
appends the existing PySymtableEntryObject on to the symtable stack and then
places a new PySymtableEntryObject into st->st_cur.  Both at this point have a
refcount of one; enough to stay alive.

Now look at symtable_exit_scope().  When the current PySymtableEntryObject is
no longer needed, it is DECREF'ed, putting it at 0 and thus leading to eventual
collection.  What is on top of the symtable stack, which has a refcount of 1
still, is then put in to st->st_cur.

So no leak.  Yes, there should be more explicit refcounting to be proper, but
the compiler cheats in a couple of places for various reasons.  But basically
everything is fine since st->st_cur and st->st_stack are only played with
refcount-wise by either symtable_enter_scope() and symtable_exit_scope() and
they are always called in pairs in the end.

-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] Proper place to put extra args for building

[Brett C.]

Martin v. LÃwis wrote:
> Brett C. wrote:
> 
>>Hmm.  OK, that is an interesting idea.  Would make rebuilding a lot easier if
>>it was just an environment variable that was part of the default OPT value;
>>``OPT="$BUILDFLAGS -g -Wall -Wstrict-prototyping".
>>
>>I say we go with that.  What is a good name, though?  PY_OPT?
> 
> 
> I think EXTRA_CFLAGS is common, and it would not specifically be part of
> OPT, but rather of CFLAGS.
> 

Works for me.  If no one objects I will check in the change for CFLAGS to make
it ``$(BASECFLAGS) $(OPT) "$EXTRA_CFLAGS"`` soon (is quoting it enough to make
sure that it isn't evaluated by configure but left as a string to be evaluated
by the shell when the Makefile is running?).

> 
>>I am only talking about that because that is how OPT is currently structured;
>>configure.in replaces the defaults with what the user provides if the
>>environment variable is set.  This is what I don't want.
> 
> 
> The question is whether the user is supposed to provide a value for OPT
> in the first place. "OPT" is a set of flag that (IMO) should control
> the optimization level of the compiler, which, in the wider sense, also
> includes the question whether debug information should be generated.
> It should be possible to link object files compiled with different
> OPT settings, so flags that will give binary-incompatible object files
> should not be in OPT.
> 

OK, that makes sense to me.

> It might be desirable to allow the user to override OPT, e.g. to specify
> that the compiler should not use -O3 but, say, -O1. I don't think there
> is much point in allowing OPT to be extended. But then, it is already
> possible to override OPT (when invoking make), which might be enough
> control.
> 

Probably.  I think as long as we state somewhere that EXTRA_CFLAGS is the place
to put binary-altering flags and to leave OPT for only binary-compatible flags
then that should be enough of a separation that most people probably won't
touch OPT most of the time since the defaults are good, but can if they want.

I assume this info should all be spelled out in the README and
Misc/Specialbuilds.txt .  Anywhere else?

-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] Reference counting when entering and exiting scopes

[Brett C.]

Guido van Rossum wrote:
>>So the two things I thought were glitches are actually cancelling each
>>other out.  Very good.  Thanks for your help.
> 
> 
> Though I wonder why it was written so delicately.

Don't know; Jeremy wrote those functions back in 2001 to add nested scopes.  If
he remembers he deserves a cookie for having such a good memory.

> Would explicit
> INCREF/DECREF really have hurt the performance that much? This is only
> the bytecode compiler, which isn't on the critical path.
> 

Probably not.  But at this point I doubt it is worth fixing since the AST
branch will replace it eventually (work is on-going, just slow since my thesis
is on the home stretch; initial draft is done and now I am editing to hand over
for final revision by my advisor).

-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] anonymous blocks

[Brett C.]

Guido van Rossum wrote:
> I've been thinking about this a lot, but haven't made much
> progess. Here's a brain dump.
> 
> I've been thinking about integrating PEP 325 (Resource-Release Support
> for Generators) into the for-loop code, so that you could replace
> 

[SNIP - using 'for' syntax to delineate the block and resource]

> So I think that this is probably not the right thing to pursue,

I totally agree with your reasoning on this.

> and we
> might be better off with something along the lines of PEP 310.  The
> authors of PEP 310 agree; under Open Issues they wrote:
> 
> There are some simiralities in concept between 'with ...' blocks
> and generators, which have led to proposals that for loops could
> implement the with block functionality[3].  While neat on some
> levels, we think that for loops should stick to being loops.
> 
> (Footnote [3] references the tread that originated PEP 325.)
> 
> Perhaps the most important lesson we've learned in this thread is that
> the 'with' keyword proposed in PEP 310 is redundant -- the syntax
> could just be
> 
> [VAR '=']* EXPR ':'
> BODY
> 
> IOW the regular assignment / expression statement gets an optional
> colon-plus-suite at the end.
> 

Sure, but is the redundancy *that* bad?  You should be able to pick up visually
that something is an anonymous block from the indentation but I don't know how
obvious it would be.

Probably, in the end, this minimal syntax would be fine, but it just seems
almost too plain in terms of screaming at me that something special is going on
there (the '=' in an odd place just quite cut if for me for my meaning of
"special").

> So now let's assume we accept PEP 310 with this change.  Does this
> leave any use cases for anonymous blocks uncovered?  Ruby's each()
> pattern is covered by generators; personally I prefer Python's
> 
> for var in seq: ...
> 
> over Ruby's much-touted
> 
> seq.each() {|var| ...}
> 
> The try/finally use case is covered by PEP 310. (If you want to
> combine this with a for-loop in a single operation, you'll need PEP
> 325.)
> 
> The use cases where the block actually returns a value are probably
> callbacks for things like sort() or map(); I have to admit that I'd
> rather keep lambda for these (and use named functions for longer
> blocks) than introduce an anonymous block syntax that can return
> values!  I also note that if you *already* have a comparison function,
> Ruby's Array sort method doesn't let you pass it in as a function
> argument; you have to give it a block that calls the comparison
> function, because blocks are not the same as callables (and I'm not
> sure that Ruby even *has* callables -- everything seems to be a
> block).
> 
> My tentative conclusion remains: Python doesn't need Ruby blocks.
> Brian Sabbey ought to come up with more examples rather than arguments
> why his preferred syntax and semantics are best.
> 

I think I agree with Samuele that it would be more pertinent to put all of this
effort into trying to come up with some way to handle cleanup in a generator.

-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] anonymous blocks

[Brett C.]

Guido van Rossum wrote:
> [Brett]
> 
>>I think I agree with Samuele that it would be more pertinent to put all of 
>>this
>>effort into trying to come up with some way to handle cleanup in a generator.
> 
> 
> I.e. PEP 325.
> 
> But (as I explained, and you agree) that still doesn't render PEP 310
> unnecessary, because abusing the for-loop for implied cleanup
> semantics is ugly and expensive, and would change generator semantics;

Right, I'm not saying PEP 310 shouldn't also be considered.  It just seems like
we are beginning to pile a lot on this discussion by bringing in PEP 310 and
PEP 325 in at the same time since, as pointed out, there is no guarantee that
anything will be called in a generator and thus making PEP 310 work in
generators does not seem guaranteed to solve that problem (although I might
have missed something; just started really following the thread today).

At this point anonymous blocks just don't seem to be happening, at least not
like in Ruby.  Fine, I didn't want them anyway.  Now we are trying to simplify
resource cleanup and handling.  What I am trying to say is that generators
differ just enough as to possibly warrant a separate discussion from all of
this other resource handling "stuff".

So I am advocating a more focused generator discussion since resource handling
in generators is much more difficult than the general case in non-generator
situations.  I mean obviously in the general case all of this is handled
already in Python today with try/finally.  But with generators you have to jump
through some extra hoops to get similar support (passing in anything that needs
to be cleaned up, hoping that garbage collection will eventually handle things,
etc.).

> and it bugs me that the finally clause's reachability depends on the
> destructor executing.
> 

Yeah, I don't like it either.  I would rather see something like:

 def gen():
FILE = open("stuff.txt", 'rU')
for line in FILE:
yield line

cleanup:
FILE.close()

and have whatever is in the 'cleanup' block be either accessible from a method
in the generator or have it become the equivalent of a __del__ for the
generator, or maybe even both (which would remove contention that whatever
needs to be cleaned up is done too late thanks to gc not guaranteeing immediate
cleanup).  This way you get the guaranteed cleanup regardless and you don't
have to worry about creating everything outside of the generator, passing it
in, and then handling cleanup in a try/finally that contains the next() calls
to the generator (or any other contortion you might have to go through).

Anyway, my random Python suggestion for the day.

-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] anonymous blocks (don't combine them with generator finalization)

[Brett C.]

Bob Ippolito wrote:
> 
> On Apr 21, 2005, at 8:59 PM, Josiah Carlson wrote:
> 
>> Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> [Brett]
>>>
 I think I agree with Samuele that it would be more pertinent to put
 all of this
 effort into trying to come up with some way to handle cleanup in a
 generator.
>>>
>>>
>>> I.e. PEP 325.
>>>
>>> But (as I explained, and you agree) that still doesn't render PEP 310
>>> unnecessary, because abusing the for-loop for implied cleanup
>>> semantics is ugly and expensive, and would change generator semantics;
>>> and it bugs me that the finally clause's reachability depends on the
>>> destructor executing.
>>
>>
>> Yes and no.  PEP 325 offers a method to generators that handles cleanup
>> if necessary and calls it close().  Obviously calling it close is a
>> mistake.  Actually, calling it anything is a mistake, and trying to
>> combine try/finally handling in generators with __exit__/close (inside
>> or outside of generators) is also a mistake.
>>
>>
>> Start by saying, "If a non-finalized generator is garbage collected, it
>> will be finalized."  Whether this be by an exception or forcing a return,
>> so be it.
>>
>> If this were to happen, we have generator finalization handled by the
>> garbage collector, and don't need to translate /any/ for loop.  As long
>> as the garbage collection requirement is documented, we are covered
>> (yay!).
> 
> 
> Well, for the CPython implementation, couldn't you get away with using
> garbage collection to do everything?  Maybe I'm missing something..
> 

[SNIP]

Well, if you are missing something then so am I since your suggestion is
basically correct.  The only issue is that people will want more immediate
execution of the cleanup code which gc cannot guarantee.  That's why the
ability to call a method with the PEP 325 approach gets rid of that worry.

-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] Proper place to put extra args for building

[Brett C.]

Martin v. LÃwis wrote:
> Brett C. wrote:
> 
>>Works for me.  If no one objects I will check in the change for CFLAGS to make
>>it ``$(BASECFLAGS) $(OPT) "$EXTRA_CFLAGS"`` soon (is quoting it enough to make
>>sure that it isn't evaluated by configure but left as a string to be evaluated
>>by the shell when the Makefile is running?).
> 
> 
> If you put it into Makefile.pre.in, the only thing to avoid that
> configure evaluates is is not to use @[EMAIL PROTECTED] OTOH, putting a $
> in front of it is not good enough for make: $EXTRA_CFLAGS evaluates
> the variable E, and then appends XTRA_CFLAGS.
> 

Yep, you're right.  I initially thought that the parentheses meant it was a
Makefile-only variable, but it actually goes to the environment for those
unknown values.

Before I check it in, though, should setup.py be tweaked to use it as well?  I
say yes.

-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] Proper place to put extra args for building

[Brett C.]

Martin v. LÃwis wrote:
> Brett C. wrote:
> 
>>Yep, you're right.  I initially thought that the parentheses meant it was a
>>Makefile-only variable, but it actually goes to the environment for those
>>unknown values.
>>
>>Before I check it in, though, should setup.py be tweaked to use it as well?  I
>>say yes.
> 
> 
> You means sysconfig.py, right?

No, I mean Python's setup.py; line 174.

> Probably yes.
> 

You mean Distutils' sysconfig, right?  I can change that as well if you want.

-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] Proper place to put extra args for building

[Brett C.]

OK, EXTRA_CFLAGS support has been checked into Makefile.pre.in and
distutils.sysconfig .  Martin, please double-check I tweaked sysconfig the way
you wanted.  I also wasn't sure of compatibility for Distutils (first time
touching it); checked PEP 291 but Distutils wasn't listed.  I went ahead and
used a genexp; hope that is okay.  I also did it through Lib/distutils instead
of the separate distutils top directory in CVS.

I didn't bother with touching setup.py because I realized that sysconfig should
take care of that.  If that is wrong let me know and I can check in a change
(and if I am right that line dealing with OPT in setup.py could probably go).

Here are the revisions.

Checking in Makefile.pre.in;
/cvsroot/python/python/dist/src/Makefile.pre.in,v  <--  Makefile.pre.in
new revision: 1.152; previous revision: 1.151
done
Checking in README;
/cvsroot/python/python/dist/src/README,v  <--  README
new revision: 1.188; previous revision: 1.187
done
Checking in Lib/distutils/sysconfig.py;
/cvsroot/python/python/dist/src/Lib/distutils/sysconfig.py,v  <--  sysconfig.py
new revision: 1.64; previous revision: 1.63
done
Checking in Misc/SpecialBuilds.txt;
/cvsroot/python/python/dist/src/Misc/SpecialBuilds.txt,v  <--  SpecialBuilds.txt
new revision: 1.20; previous revision: 1.19
done
Checking in Misc/NEWS;
/cvsroot/python/python/dist/src/Misc/NEWS,v  <--  NEWS
new revision: 1.1288; previous revision: 1.1287
done

-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] Re: anonymous blocks

[Brett C.]

Guido van Rossum wrote:
[SNIP]
> Now let me propose a strawman for the translation of the latter into
> existing semantics. Let's take the generic case:
> 
> with VAR = EXPR:
> BODY
> 
> This would translate to the following code:
[SNIP]
> 
> it = EXPR
> err = None
> while True:
> try:
> VAR = it.next(err)
> except StopIteration:
> break
> try:
> err = None
> BODY
> except Exception, err: # Pretend "except Exception:" == "except:"
> pass
> 
> but for backwards compatibility with the existing argument-less next()
> API I'm introducing a new iterator API next_ex() which takes an
> exception argument.

Can I suggest the name next_exc() instead?  Everything in the sys module uses
"exc" as the abbreviation for "exception".  I realize you might be suggesting
using the "ex" as the suffix because of the use of that as the suffix in the C
API for an extended API, but that usage is not prominent in the stdlib.

Also, would this change in Python 3000 so that both next_ex() and next() are
merged into a single method?

As for an opinion of the need of 'with', I am on the fence, leaning towards
liking it.  To make sure I am understanding the use case, it is to help
encapsulate typical resource management with proper cleanup in another function
instead of having to constantly pasting in boilerplate into your code, right?
So the hope is to be able to create factory functions, typically implemented as
a generator, that encapsulate the obtaining, temporary lending out, and cleanup
of a resource?

Is there some other use that I am totally missing that is obvious?

>  If that argument is None, it should behave just
> like next().  Otherwise, if the iterator is a generator, this will
> raised that exception in the generator's frame (at the point of the
> suspended yield).  If the iterator is something else, the something
> else is free to do whatever it likes; if it doesn't want to do
> anything, it can just re-raise the exception.
> 
> Also note that, unlike the for-loop translation, this does *not*
> invoke iter() on the result of EXPR; that's debatable but given that
> the most common use case should not be an alternate looping syntax
> (even though it *is* technically a loop) but a more general "macro
> statement expansion", I think we can expect EXPR to produce a value
> that is already an iterator (rather than merely an interable).
> 
> Finally, I think it would be cool if the generator could trap
> occurrences of break, continue and return occurring in BODY.  We could
> introduce a new class of exceptions for these, named ControlFlow, and
> (only in the body of a with statement), break would raise BreakFlow,
> continue would raise ContinueFlow, and return EXPR would raise
> ReturnFlow(EXPR) (EXPR defaulting to None of course).
> 
> So a block could return a value to the generator using a return
> statement; the generator can catch this by catching ReturnFlow.
> (Syntactic sugar could be "VAR = yield ..." like in Ruby.)
> 
> With a little extra magic we could also get the behavior that if the
> generator doesn't handle ControlFlow exceptions but re-raises them,
> they would affect the code containing the with statement; this means
> that the generator can decide whether return, break and continue are
> handled locally or passed through to the containing block.
> 

Honestly, I am not very comfortable with this magical meaning of 'break',
'continue', and 'return' in a 'with' block.  I realize 'return' already has
special meaning in an generator, but I don't think that is really needed
either.  It leads to this odd dichotomy where a non-exception-related statement
directly triggers an exception in other code.  It seems like code doing
something behind my back; "remember, it looks like a 'continue', but it really
is a method call with a specific exception instance.  Surprise!"

Personally, what I would rather see, is to have next_ex(), for a generator,
check if the argument is a subclass of Exception.  If it is, raise it as such.
 If not, have the 'yield' statement return the passed-in argument.  This use of
it would make sense for using the next_ex() name.

Then again I guess having exceptions triggering a method call instead of
hitting an 'except' statement is already kind of "surprise" semantics anyway.
=)  Still, I would like to minimize the surprises that we could spring.

And before anyone decries the fact that this might confuse a newbie (which
seems to happen with every advanced feature ever dreamed up), remember this
will not be meant for a newbie but for someone who has experience in Python and
iterators at the minimum, and hopefully with generators.  Not exactly meant for
someone for which raw_input() still holds a "wow" factor for.  =)

> Note that EXPR doesn't have to return a generator; it could be any
> object that implements next() and next_ex().  (We could also require
> next_ex() or even next(