[Python-Dev] Fwd: CFP: DLS05: ACM Dynamic Languages Symposium

[Guido van Rossum]

See you all at OOPSLA!

-- Forwarded message --
From: Roel Wuyts <[EMAIL PROTECTED]>
Date: Apr 17, 2005 10:59 PM
Subject: CFP: DLS05: ACM Dynamic Languages Symposium
To: python-announce-list@python.org


CALL FOR PAPERS FOR THE

ACM Dynamic Languages Symposium 2005
 October 18, 2005
 San Diego, California
   (co-located with OOPSLA'05)

URL: http://decomp.ulb.ac.be:8082/events/dls05/

---
Abstract
---

In industry, static languages (such as Java, C++ and C#) are much more
widely used than their dynamic counterparts (like CLOS, Python, Self,
Perl, php or Smalltalk). So it appears as though dynamic language
concepts were forgotten and lost the race.

But this is not the case.

Java and C#, the latest mainstream static languages, popularized to a
certain extent dynamic language features such as garbage collection,
portability and (limited forms of) reflection. In the near future, we
expect this dynamicity to increase even further. E.g., it is getting
clearer year after year that pervasive computing is becoming the rule
and that concepts such as meta programming, reflection, mobility,
dynamic reconfigurability and distribution are becoming increasingly
popular. All of these features are the domain of dynamic languages, and
hence it is only logical that more dynamic language concepts have to be
taken up by static languages, or that dynamic languages can make a
breakthrough.

Currently, the dynamic language community is fragmented, split over a
multitude of paradigms (from functional over logic to object-oriented),
languages and syntaxes. This fragmentation severely hinders research as
well as acceptance, and results in either language wars or, even worse,
language ignorance. The goal of this symposium is to provide a highly
visible, international forum for researchers working on dynamic
features and languages. We explicitly invite submissions from all kinds
of paradigms (object-oriented, functional, logic, ...), as can be seen
from the structure of the program committee.

Areas of interests include, but are not limited to:
- closures
- delegation
- actors, active objects
- constraint systems
- mixins and traits
- reflection and meta-programming
- language symbiosis and multi-paradigm languages
- experience reports on successful application of dynamic languages

Accepted Papers will be published in the ACM Digital Library.

---
Submission Guidelines
---

Papers will need to be submitted using an online tracking system, of
which the URL will be given later.

All papers must be submitted electronically in PDF format (or
PostScript, if you do not have access to PDF-producing programs, but
this is not recommended). Submissions, as well as final versions, must
be formatted to conform to ACM Proceedings requirements: Nine point
font on ten point baseline, two columns per page, each column 3.33
inches wide by 9 inches tall, with a column gutter of 0.33 inches, etc.
See the ACM Proceedings Guidelines. You can save preparation time by
using one of the templates from that page. Note that MS Word documents
must be converted to PDF before being submitted.

--
  Important Dates
--

- Deadline for receipt of submissions: June 24th 2005
- Notification of acceptance or rejection: August 5th 2005
- Final version for the proceedings: To be announced later

---
Program Committee
---

- Gilad Bracha
- Wolfgang De Meuter
- Stephane Ducasse
- Gopal Gupta
- Robert Hirschfeld
- Dan Ingalls
- Yukihiro Matsumoto
- Mark Miller
- Eliot Miranda
- Philippe Mougin
- Oscar Nierstrasz
- Dave Thomas
- David Ungar
- Guido Van Rossum
- Peter Van Roy
- Jon L White (G)
- Roel Wuyts (Chair)

--
Roel Wuyts
   DeComp
[EMAIL PROTECTED]   Université Libre de
Bruxelles
http://homepages.ulb.ac.be/~rowuyts/
Belgique
Vice-President of the European Smalltalk Users Group: www.esug.org

--
http://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations.html


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

[Python-Dev] python-dev Summary for 2005-04-01 through 2005-04-15 [draft]

[Tim Lesher]

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.

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.

[TDL]

=
Summaries
=

--
Right Operator Methods
--

Greg Ewing explored an issue with new-style classes that define only
right operator methods (__radd__, __rmul__, etc.)  Instances of such
a class cannot be added/multiplied/etc. together as Python raises a
TypeError. Armin Rigo explained the rule: if the instances on both sides
of an operator are of the same class, only the non-reversed method is
ever called. Armin also explained that an __add__ or __mul__ method that
returns NotImplemented may be called twice when Python attempts to
differentiate between numeric and sequence operations.

Contributing threads:

- `New style classes and operator methods
`__

[SJB]

--
Hierarchical groups in regular expressions
--

Chris Ottrey demoed his `pyre2 project`_ that can extract a hierarchy of
strings when nested groups match in a regular expression.  The current
re module (in the stdlib) only matches the last occurrence of a group in
the string, throwing away any preceding matches. People discussed some
of pyre2's proposed API, with the main suggestion being to extend the
API to support unnamed (positional) groups in addition to named groups.

Though a number of people expressed interest in the idea, it was not
clear whether the functionality should be included in the standard
library. However, most agreed that if it was included, it should
be integrated with the existing re module. Gustavo Niemeyer offered to
perform this integration if an API could be agreed upon. Further
discussion was moved to the pyre2 `development wiki`_ and `mailing
list`_.

Contributing threads:

- `hierarchicial named groups extension to the re library
`__

.. _pyre2 project: http://pyre2.sourceforge.net/

.. _development wiki: http://py.redsoft.be/pyre2/wiki/

.. _mailing list: http://lists.sourceforge.net/lists/listinfo/pyre2-devel

[SJB]

---
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
access the attributes used in the proxy class, you need to access
things like im_func or func_closure, which are not accessible in
restricted execution mode.

James Y Knight illustrated how strategic overriding of __eq__ in a
subclass of str could allow access to the hidden "facets". Eyal Lotem
suggested that such an attack could be countered by implementing
"facets" in C, but having to turn to C every time you needed a
particular security construct seemed unappealing.

Contributing threads:

- `Security capabilities in Python
`__

.. _some code: http://zesty.ca/python/facet.py

[SJB]

-
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 P

Re: [Python-Dev] Security capabilities in Python

[M.-A. Lemburg]

Eyal Lotem wrote:
I would like to experiment with security based on Python references as
security capabilities.
Unfortunatly, there are several problems that make Python references
invalid as capabilities:
* There is no way to create secure proxies because there are no
private attributes.
* Lots of Python objects are reachable unnecessarily breaking the
principle of least privelege (i.e: object.__subclasses__() etc.)
I was wondering if any such effort has already begun or if there are
other considerations making Python unusable as a capability platform?
You might want to have a look at mxProxy objects. These
were created to provide secure wrappers around Python
objects with a well-defined access mechanism, e.g.
by defining a list of methods/attributes which can
be accessed from the outside or by creating a method
which then decides whether access is granted or not:
   http://www.egenix.com/files/python/mxProxy.html
Note that the new-style classes may have introduced some
security leaks. If you find any, please let me know.
PS: A nice side-effect of the these proxy objects is that
you can create weak-reference to all Python objects (not just
those that support the protocol).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source  (#1, Apr 18 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
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]

[Michael Hudson]

Tim Lesher <[EMAIL PROTECTED]> writes:

> 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.

Nice work!

An update:

> -
> 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, 

Nevertheless, I've checked one of them in :) After reading a fair bit
of code, and docs, I went for option 2) in the linked mail.

> 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."

I think this reading is a bit of a stretch of the wording of the PEP.
It also contradicts the documentation ("regardless of the current
state of Python").

Finally, the current behaviour has a strong whiff of being accidental.

> 
> 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-dependant accident,
> because Python is written to C89, which has no such concepts.  Tim Peters
> pointed out all code for (de)serialing C doubles should go through
> _PyFloat_Pack8()/_PyFloat_Unpack8(), and that the current implementation
> suggests that the routines could simply copy bytes on platforms that use the
> standard IEEE-754 single and double formats natively.  Michael Hudson
> obliged by creating a `patch to implement this`_.

I hope to check this in soon.  Note that the patch is in two pieces,
one to marshal floats in binary format and one ...

> The consensus was that the correct behaviour is that packing a NaN or
> infinity shouldn't cause an exception.  When unpacking, an IEEE-754 platform
> shouldn't cause an exception, but a non-754 platform should, since there's
> no sensible value that it can be unpacked to, and errors should never pass
> silently.

... to do this bit.

> -
> Location of the sign bit in longs
> -
>
> Michael Hudson asked about the possibility of longs storing the sign bit
> somewhere other than the current location, suggesting the top bit of
> ob_digit[0].  Tim Peters suggested that it would be better to give struct
> _longobject a distinct sign member.  This simplifies code, costs no extra
> bytes for some longs, and 8 extra bytes for others, and shouldn't hurt
> binary compatibility.
>
> Michael coughed up a `longobject patch`_, which seems likely to be checked
> in.

I'm actually in less of a rush to get this one in :)

(Hmm, had a busy couple of weeks, didn't I? :)

> Contributing threads:
>
>  - `marshal / unmarshal
> `__

?

Cheers,
mwh

-- 
   we should write an os
   YES
  * itamar starts a sourceforge project
-- from Twisted.Quotes
___
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]

[Aahz]

On Mon, Apr 18, 2005, 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.

  Good show!

One suggestion: might want to order threads in order of relevance to
random python-dev readers (the bit that triggered this comment was
seeing the unified vs. context diffs thread so far down).
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

"The joy of coding Python should be in seeing short, concise, readable
classes that express a lot of action in a small amount of clear code -- 
not in reams of trivial code that bores the reader to death."  --GvR
___
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

Re: [Python-Dev] python-dev Summary for 2005-04-01 through 2005-04-15 [draft]

[Walter Dörwald]

Tim Lesher sagte:

> 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.
> [...]
> 
> 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
> evolution, the consensus was that BOM and signature handling belong at a 
> higher level (for example, a stream API) than the
> codec.

All codecs provide a stream API, so there is no higher level.

Bye,
   Walter Dörwald




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

[Raymond Hettinger]

> ==
> Summary Announcements
> ==

Executive summary:  Hudson goes wild fixing obscure bugs.


> ---
> 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. 

Both your process and results are excellent.


Raymond Hettinger
___
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] Pickling buffer objects.

[Travis Oliphant]

Before submitting a patch to pickle.py and cPickle.c,  I'd be interested 
in knowing how likely to be accepted a patch that allows Python to 
pickle the buffer object.

The problem being solved is that Numeric currently has to copy all of 
its data into a string before writing it out to a pickle.  Yes, I know 
there are ways to write directly to a file.  But,  it is desireable to 
have Numeric arrays interact seamlessly with other pickleable types 
without a separate stream.   This is especially utilized for network 
transport. 

The patch would simply write the opcode for a Python string to the 
stream and then write the character-interpreted data (without making an 
intermediate copy) of the void * pointer of the buffer object. 

Yes, I know all of the old arguments about the buffer object and that it 
should be replaced with something better.I've read all the old posts 
and am quite familiar with the issues about it.

But, this can be considered a separate issue.  Since the buffer object 
exists, it ought to be pickleable, and it would make a lot of 
applications a lot faster.  

I'm proposing to pickle the buffer object so that it unpickles as a 
string.  Arguably, there should be a separate mutable-byte object opcode 
so that buffer objects unpickle as mutable-byte buffer objects.   If 
that is more desireable, I'd even offer a patch to do that (though such 
pickles wouldn't unpickle under earlier versions of Python).   I suspect 
that the buffer object would need to be reworked into something more 
along the lines of the previously-proposed bytes object before a 
separate bytecode for pickleable mutable-bytes is accepted, however.

-Travis Oliphant
___
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] Pickling buffer objects.

[Greg Ewing]

Travis Oliphant wrote:
I'm proposing to pickle the buffer object so that it unpickles as a 
string.
Wouldn't this mean you're only solving half the problem?
Unpickling a Numeric array this way would still use an
intermediate string.
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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] Pickling buffer objects.

[Martin v. Löwis]

Greg Ewing wrote:
> Wouldn't this mean you're only solving half the problem?
> Unpickling a Numeric array this way would still use an
> intermediate string.

Precisely my concern.

Martin

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