Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Samuele Pedroni]

On Thu, Oct 4, 2018 at 10:58 AM Steven D'Aprano  wrote:

> While keyword arguments have to be identifiers, using **kwargs allows
> arbitrary strings which aren't identifiers:
>
> py> def spam(**kwargs):
> ... print(kwargs)
> ...
> py> spam(**{"something arbitrary": 1, '\n': 2})
> {'something arbitrary': 1, '\n': 2}
>
>
> There is some discussion on Python-Ideas on whether or not that
> behaviour ought to be considered a language feature, an accident of
> implementation, or a bug.
>
>
I would expect this to be costly/annoying for implementations to enforce,
doing it at call time is probably too late to be efficient, it would need
help from dicts themselves or even strings.

A hack that currently works because of this is with dict itself:

>>> d = {'a-1': 1, 'a-2': 2, 'a-3': 3}
>>> d1 = dict(d, **{'a-2': -2, 'a-1': -1})
>>> d1 is d
False
>>> d1
{'a-1': -1, 'a-2': -2, 'a-3': 3}
>>>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?

[Samuele Pedroni]

Victor Stinner wrote:

Le Tuesday 17 February 2009 08:52:20 Lennart Regebro, vous avez écrit :
  

On Tue, Feb 17, 2009 at 00:50, Guido van Rossum  wrote:


Can you explain the difficulty with porting setuptools in more detail?
  

Oh, it just exposes a bug in distutils. It probably means I'll have to
make a test for python version, and if it is 3.0.1, monkey-patch
distutils. I haven't really looked into if there is any other
possibilities yet, I'm concentrating to make it run for 3.1 trunk
first.



  
Didn't a test fail because of this? seems the underlying issue is that 
this part of the stdlib didn't have enough test coverage. It seems that 
having very good/improving test coverage like is recommended  for 
3rd-party project wanting to switch would be a good goal for 3.0 
evolution too. We know from PyPy experience that while always improving 
the test suite coverage is quite spotty at times.


___
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] Reviving restricted mode?

[Samuele Pedroni]

Guido van Rossum wrote:

I've received some enthusiastic emails from someone who wants to
revive restricted mode. He started out with a bunch of patches to the
CPython runtime using ctypes, which he attached to an App Engine bug:

http://code.google.com/p/googleappengine/issues/detail?id=671

Based on his code (the file secure.py is all you need, included in
secure.tar.gz) it seems he believes the only security leaks are
__subclasses__, gi_frame and gi_code. (I have since convinced him that
if we add "restricted" guards to these attributes, he doesn't need the
functions added to sys.)

I don't recall the exploits that Samuele once posted that caused the
death of rexec.py -- does anyone recall, or have a pointer to the
threads?

  
I don't have much time these days, for sure not until pycon us, to look 
at the proposed code.


A remark though, in many cases people want to use restricted execution 
to allow trusted and untrusted code to live side by side. In such a 
scenario the issue is not only how to prevent for example the untrusted 
code to get hold of open() but also how to deal with the security issues 
at the boundary when untrusted code calls into trusted code. AFAIK E 
provides and incorporate a lot of thinking around the concept of guards, 
a sort of generalized runtime "type checking" with very strong 
guarantees, in a language like Java instead type checking and final 
classes can be used to provide the required safety. Python instead over 
the years has grown more hooks for object to cheat about their types. In 
general safely programming such trusted code in python will be delicate 
and slightly cumbersome. Think for example of thinhs that can be done by 
objects redefining equality wrt data structures that old sensitive 
information unless such arguments are blocked.



___
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] Challenge: Please break this! [Now with blog post]

[Samuele Pedroni]

Guido van Rossum wrote:

On Mon, Feb 23, 2009 at 3:16 PM, "Martin v. Löwis"  wrote:
  

Don't I remember the previous restricted module dying a similar "death
of 1,000 cuts" before it was concluded to be unsafe at any height and
abandoned?
  

I think you are slightly misremembering. It got cut again and again,
but never died. Then, new-style classes hit an artery, and it bled
to death.

I'm curious how this one fares.



FWIW, I am remembering more about how Samuele cracked it. It had to do
with getting the supervisor code to call one of its own functions with
arguments provided by the sandboxed code. Tav's safelite.py doesn't
seem to be directly exploitable that way because (using ctypes hacks)
it *removes* some offending special methods. But that door would be at
least slightly ajar with Tar's proposed patch to Python, as that
doesn't remove the offending attributes (__subclasses__ etc.); it only
forbids them in restricted mode. But this once again enables Samuele's
hack. (Oh if I only could find the link with the actual attack -- it
was quite a bit more devious than attacks linked to so far.)

  

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

Re: [Python-Dev] Using SCons for cross-compilation

[Samuele Pedroni]

Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Nov 9, 2006, at 2:15 PM, [EMAIL PROTECTED] wrote:
>
>   
>> Martin> In any case, the patch being contributed uses SCons. If  
>> people
>> Martin> think this is unmaintainable, this is a reason to  
>> reject the
>> Martin> patch.
>>
>> Could SCons replace distutils?
>> 
>
> I'm not so sure.  I love SCons, but it has some unpythonic aspects to  
> it, which (IMO) make sense as a standalone build tool, but not so  
> much as a standard library module.  I'd probably want to see some of  
> those things improved if we were to use it to replace distutils.
>
>   
in PyPy we explored at some point using SCons instead of abusing 
distutils for our building needs,
it seems to have a library part but a lot of its high-level dependency 
logic seems to be coded
in what is its main invocation script logic in a monolithic way and with 
a lot of global state.
We didn't feel like trying to untangle that or explore more.
> There does seem to be overlap between the two tools though, and it  
> might make for an interesting sprint/project to find and refactor the  
> commonality.
>
> - -Barry
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.5 (Darwin)
>
> iQCVAwUBRVObXHEjvBPtnXfVAQIhQQP/esS6o+7NX/JenJcuEdvb7rWIVxRgzVEh
> rfZGSOO2mp6b0PgrvXjAnZQHYJFpQO5JXpWJVqLBPxbucbBwvWaA0+tgTrpnBpj9
> Cs/vwlMsmk55CwSYjvl7eM0uW9aIuT9QcZxuf4j+T7dzQOL0LL2Id4/876Azcfo0
> 7A0dtc2oJ+U=
> =H1w2
> -END PGP SIGNATURE-
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/pedronis%40strakt.com
>   

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

Re: [Python-Dev] Fwd: survey about the use of agile practices

[Samuele Pedroni]

Aahz wrote:
> On Sun, Dec 24, 2006, Guido van Rossum wrote:
>   
>> Anyone?
>> 
>
> It was discarded as probable spam by me due to the lack of a valid "To:"
> line.  Do you have any particular reason for believing that it's real?
>   
http://agile.diee.unica.it/uras.html (it's in italian)

seems to make this credible. FWIW.
___
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] pypy-0.99.0: new object spaces, optimizations, configuration ...

[Samuele Pedroni]

=
pypy-0.99.0: new object spaces, optimizations, configuration ...
=
Welcome to the PyPy 0.99.0 release - a major snapshot
and milestone of the last 8 months of work and contributions
since PyPy-0.9.0 came out in June 2006!

Main entry point for getting-started/download and documentation:

http://codespeak.net/pypy/dist/pypy/doc/index.html

Further below you'll find some notes about PyPy,
the 0.99.0 highlights and our aims for PyPy 1.0.

have fun,

the PyPy team,
Samuele Pedroni, Carl Friedrich Bolz, Armin Rigo, Michael Hudson,
Maciej Fijalkowski, Anders Chrigstroem, Holger Krekel,
Guido Wesdorp

and many others:
http://codespeak.net/pypy/dist/pypy/doc/contributor.html


What is PyPy?


Technically, PyPy is both a Python Interpreter implementation
and an advanced Compiler, actually a framework for implementing
dynamic languages and generating virtual machines for them.
The Framework allows for alternative frontends and
for alternative backends, currently C, LLVM and .NET. 
For our main target "C", we can can "mix in" different Garbage
Collectors and threading models, including micro-threads aka
"Stackless".  The inherent complexity that arises from this
ambitious approach is mostly kept away from the Python
interpreter implementation, our main frontend.

Socially, PyPy is a collaborative effort of many individuals
working together in a distributed and sprint-driven way since
2003.  PyPy would not have gotten as far without the coding,
feedback and general support from numerous people.

Formally, many of the current developers are involved in
executing an EU contract with the goal of exploring and
researching new approaches to Language/Compiler development and
software engineering.  This contract's duration is about to
end March 2007 and we are working and preparing the according
final review which is scheduled for May 2007. 


Key 0.99.0 Features
=

* new object spaces:

  - Tainting: a 270-line proxy object space tracking
and boxing sensitive information within an application.
A tainted object is completely barred from crossing
an I/O barrier, such as writing to files, databases
or sockets.  This allows to significantly reduce the
effort of e.g. security reviews to the few places where
objects are "declassified" in order to send information
across I/O barriers.

  - Transparent proxies: allow to customize both application and
builtin objects from application level code.  Works as an addition
to the Standard Object Space (and is translatable). For details see
http://codespeak.net/pypy/dist/pypy/doc/proxy.html
 
* optimizations:

  - Experimental new optimized implementations for various built in Python
types (strings, dicts, lists)

  - Optimized builtin lookups to not require any dictionary lookups if the
builtin is not shadowed by a name in the global dictionary.

  - Improved inlining (now also working for higher level
backends) and malloc removal.

  - twice the speed of the 0.9 release, overall 2-3 slower than CPython

* High level backends:

  - It is now possible to translate the PyPy interpreter to run on the .NET
platform, which gives a very compliant (but somewhat slow) Python
interpreter.

  - the JavaScript backend has evolved to a point where it can be used 
to write
AJAX web applications with it. This is still an experimental technique,
though. For demo applications see:
http://play1.codespeak.net:8008/

* new configuration system:
  There is a new comprehensive configuration system that allows
  fine-grained configuration of the PyPy standard interpreter and the
  translation process.

* new and improved modules: Since the last release, the signal, mmap, bz2
  and fcntl standard library modules have been implemented for PyPy. The 
socket,
  _sre and os modules have been greatly improved. In addition we added a the
  pypymagic module that contains PyPy-specific functionality.

* improved file implementation: Our file implementation was ported to 
RPython
  and is therefore faster (and not based on libc).

* The stability of stackless features was greatly improved. For more details
  see: http://codespeak.net/pypy/dist/pypy/doc/stackless.html

* RPython library: The release contains our emerging RPython library 
that tries
  to make programming in RPython more pleasant. It contains an experimental
  parser generator framework. For more details see:
  http://codespeak.net/pypy/dist/pypy/doc/rlib.html

* improved documentation:
 
  - extended documentation about stackless features:
http://codespeak.net/pypy/dist/pypy/doc/stackless.html
 
  - PyPy video documentation: eight hours of talks, interviews and features:
http://codespeak.net/pypy/dist/pypy/doc/vid

Re: [Python-Dev] PEP 8: Discourage named lambdas?

[Samuele Pedroni]

Terry Reedy wrote:

Some people write
somename = lambda args: expression
instead of the more obvious (to most people) and, dare I say, standard
def somename(args): return expression

The difference in the result (the only one I know of) is that the code and 
function objects get the generic name '' instead of the more 
informative (in repr() output or tracebacks) 'somename'.  I consider this a 
disadvantage.


In the absence of any compensating advantages (other than the trivial 
saving of 3 chars), I consider the def form to be the proper Python style 
to the point I think it should be at least recommended for the stdlib in 
the Programming Recommendations section of PEP 8.


There are currently uses of named lambdas at least in urllib2.  This to me 
is a bad example for new Python programmers.


What do our style mavens think?
  

I found only an example in my personal recent code:

START = ""
END = ""
TITLEPATTERN = lambda s: "%s" % s

this three are later used in a very few .find() and .replace() 
expressions in the same module. I suppose my point is that while I agree 
it should be discouraged and is really silly to do it for the few chars 
gain, it can be used to some effect in very rare cases.


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

Re: [Python-Dev] PEP 8: Discourage named lambdas?

[Samuele Pedroni]

Nick Coghlan wrote:

Samuele Pedroni wrote:

I found only an example in my personal recent code:

START = ""
END = ""
TITLEPATTERN = lambda s: "%s" % s

this three are later used in a very few .find() and .replace() 
expressions in the same module. I suppose my point is that while I 
agree it should be discouraged and is really silly to do it for the 
few chars gain, it can be used to some effect in very rare cases.


The way that's written currently, I think I could *very* easily miss 
the fact that TITLEPATTERN is a callable while glancing over the code 
(and be very confused if I later saw it being called or passed as a 
callback).


confused? maybe, "very" seems an overstatement
___
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] 2.4 news reaches interesting places

[Samuele Pedroni]

Guido van Rossum wrote:
I was pleasantly surprised to find a pointer to this article in a news
digest that the ACM emails me regularly (ACM TechNews).
http://gcn.com/vol1_no1/daily-updates/28026-1.html
One thing that bugs me: the article says 3 or 4 times that Python is
slow, each time with a refutation ("but it's so flexible", "but it's
fast enough") but still, they sure seem to harp on the point. This is
a PR issue that Python needs to fight -- any ideas?
I think that right now there is a promising ongoing happening that
may be useful for this PR problem and Python perception in general,
which is the Chandler project, because it's a piece of software that may 
end up in front of lot of people. It is both an opportunity and a risk.

A not great success of Chandler especially if imputed to Python
shortcomings would be bad.
I think that people with long-time Python experience that feel like to 
contribute should try.

A successful, responsive Chandler, I think, would be a good thing for
Python.
___
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 309 enhancements

[Samuele Pedroni]

Nick Coghlan wrote:
The initial suggestion was to provide a __get__ method on partial 
objects, which forces the insertion of the reference to self at the 
beginning of the argument list instead of at the end:

def __get__(self, obj, type=None):
if obj is None:
return self
return partial(self.fn, obj, *self.args, **self.kw)
just a note:
I don't see why this is not also a possible definition:
return partial(self.fn, *(self.args+(obj,)), **self.kw)
it may be impractical, but it would implement the direct mechanics of 
partial should behave like a function.
___
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()

[Samuele Pedroni]

Peter Astrand wrote:
On Fri, 11 Mar 2005, Paul Moore wrote:
 

Not sure this is pertinent but anyway: "any" and "all" are often used
as variable names. "all" especially often and then almost always as a
list of something. It would not be good to add "all" to the list of
words to watch out for. Also, "all" is usually thought of as a list of
 

 

Using "any" and "all" as variables hides the builtins, but doesn't
disallow their use elsewhere. Personally, though, I wouldn't use "any"
or "all" as variable names, so that's a style issue.
   

Even though you can use them as variables (and shadow the builtins), you
will still get warnings from "pychecker". The code will also be harder to
read: When you see "all" in the middle of some code, you don't know if
it's referring to the builtin or a variable.
Personally, I think Python has too many builtins already.
 

to extend the naming pool, FWIW CL calls similar things EVERY and SOME.

___
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] code blocks using 'for' loops and generators

[Samuele Pedroni]

Brian Sabbey wrote:
be guaranteed to run under all conditions, I think it would be
useful if it could be arranged so that
for x in somegenerator(): ... raise Blather ...
would caused any finallies that the generator was suspended inside
to be executed. Then the semantics would be the same as if the
for-loop-over-generator were implemented by passing a thunk to a
function that calls it repeatedly.

One difficulty is that one can never know if the user intends to
still use the generator, like so:
a = somegenerator() try: for x in a: raise Blather except: a.next()
I think they only way you can really be sure .next() will not be
called again is if the generator is no longer referenced.  Someone
submitted a patch once to execute "finallies" when the generator is
__del__eted, but it was rejected for various reasons.
In my original post in this thread I tried to provide a mechanism
such as you describe by providing __call__ as an alternative to
'next', but now I am convinced that it is better to introduce a new
syntax instead of re-using generators.
Incidentally, passing the thunk "behind the scenes" as the first 
argument (as mentioned previously) allows one to avoid using lambda
to do things such as sort (I hear lambdas are on the way out), while
 remaining anonymous:

with x, y from a.sort(): value cmp(x.k1, y.k1) or (x.k2, y.k2)
(or whatever the preferred syntax is) instead of:
a.sort(lambda x,y : cmp(x.k1, y.k1) or (x.k2, y.k2))
Not that I find either form better than the other, but I do find both
 better than have to define a named function.

Notice that syntax is the key issue here, it is not like it is hard to
think a range of semantics for thunks/anonymous functions. In fact 
thunks can probably be just closures with some tweaks up to the yield issue.

In fact if some unnatural (for Python POV likely) parentheses would be
acceptable but they are very likely not, it is simple to devise
syntaxes that allows anonymous functions pretty much everywhere. This
would allow for some rather unwieldy code.
OTOH a suite-based syntax for thunks can likely not work as a substitute 
of lambda for cases like:

f(lambda: ..., ...)
where the function is the first argument, and then there are further 
arguments. (Of course not-so-natural helper functions can be written
to swap arguments around).

Apart this one very hard problem, it would be nice to be able to define
and pass more thunks simultaneously. In particular a more concise syntax for
  def setx(self, v): self._x = v
  def getx(self): return self._x
  x = property(getx,setx)
was considered in the past discussions about the topic a worthy goal.
regards




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

Re: [Python-Dev] code blocks using 'for' loops and generators

[Samuele Pedroni]

Brian Sabbey wrote:
Samuele Pedroni wrote:
OTOH a suite-based syntax for thunks can likely not work as a 
substitute of lambda for cases like:

f(lambda: ..., ...)
where the function is the first argument, and then there are further 
arguments.

I do not see why you say suite-based thunks cannot be used in the case 
in which the function takes more than one argument.  Using the syntax I 
described earlier, they work in just that way:

def pickled_file(thunk, name):
...
new_data = thunk(pickle.load(f))
...
with greetings from pickled_file('greetings.pickle'):
...
value greetings
One can make an analogy with "self".  Both the thunk and self can be 
passed automatically as the first argument, and further arguments can 
follow.  In this way, functions that already take a thunk as a first 
argument (such as sort) can be re-used without modification.
Of course now one has a problem with things that take functions as last
arguments, wich if I rembember correctly is the natural position in
Ruby. Unless the syntax involve placeholders (likely icky) one is going
to have this kind of limitations. My point is that a suite-based syntax
can only be a half substitute for lambda and anyway requiring a suite
seems overkill and unnatural for the just 1 expression case, for example
predicates. IOW a suite-based syntax is not a lambda killer in itself, I
would not try to stress that point.
Apart this one very hard problem, it would be nice to be able to define
and pass more thunks simultaneously. In particular a more concise 
syntax for

 def setx(self, v): self._x = v
 def getx(self): return self._x
 x = property(getx,setx)
was considered in the past discussions about the topic a worthy goal.

Here I can make another analogy with self.  Just as python does not give 
syntactic support for multiple dispatch because (I assume) it would 
require major syntax changes 
multiple dispatch has nothing to do with syntax, in fact usual call
syntax is sufficient, and people do use multiple dispatch sometimes,
and decorators now can be even used to sugar up the definition side
of it.
for something that would be rarely used, I 
do not think
well that's up to discussion to discover
 it is worth it to give syntactic support for multiple
thunks. If only a fraction "epsilon" of functions take a single thunk, 
then I would guess that "epsilon**2" take two thunks, and it is not 
worth creating syntax for such a small number of cases, especially if 
that syntax compromises what would otherwise be a much cleaner syntax 
for the single thunk case.

well, but this is stated without even trying to come up with a syntax
for that case. Notice that the first time around Guido himself would
have preferred if achievable a multithunk syntax, he obviously can have
changed his mind. But, yes, syntax vs expressivity is the key issue here.
___
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: code blocks using 'for' loops and generators

[Samuele Pedroni]

Jim Jewett wrote:
It may be time to PEP (or re-PEP), if only to clarify what people are 
actually asking for.

Brian Sabbey's example from message 
http://mail.python.org/pipermail/python-dev/2005-March/052202.html
*seems* reasonably clear, but I don't see how it relates in any way to
"for" loops or generators, except as one (but not the only) use case.

def add(thunk1, thunk2, other):
print thunk1(1,2) + thunk2(3,4) + other
with x,y from add(100):
value x*y
also a,b:   # yikes??
value a*b   # this is thunk2
To make my own understanding explicit:
(1)  Calls for "Ruby blocks" or "thunks" are basically calls for 
placeholders in a function.  These placeholders will be filled
with code from someplace else, but will execute in the function's
own local namespace.  

(2)  A function as a parameter isn't good enough, because the 
passed-in function can't see bindings in the surrounding larger 
function.  (It still sees the lexical scope it which it was defined.)

(3)  A function as a parameter isn't good enough, because the
passed-in function can't modify bindings in the surrounding
larger function.  

(4)  A thunk could be used today be creating a string (rather than
a pre-compiled function) and substituting in the thunk's string
(rather than the code to which it would compile) before execution,
though this would be ugly.
(5)  A thunk *might* be do-able with exec or eval if a function's
locals were still a dictionary.
notice that while closures with the current semantics of def cannot 
rebind, the internal mechanism for closures is perfectly capable of 
supporting rebinding. So thunks could be function objects.


(6)  This has nothing whatsoever to do with for loops or generators,
except as a common use case.  In particular, thunks may be used
to lock/unlock or unwind-protect some resource.  Generators are
not the only place this is needed, but they have made the "what
do you mean, __del__ might never get called?" problem even worse,
and Ruby often solves these with a Ruby Block.
(7)  A __leave__ or __exit__ special method really turns into another
name for __del__.  It might still be useful if it came with semantics
of "I explicitly don't care what order cycles are broken; call me as
soon as my object is garbage and who cares if it gets resurrected."
There have been recipes (from Tim?) for emulating this by using 
a proxy to the resource, so that no __del__ cycles can form.

-jJ
___
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/pedronis%40strakt.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] code blocks using 'for' loops and generators

[Samuele Pedroni]

Josiah Carlson wrote:
Greg Ewing <[EMAIL PROTECTED]> wrote:
Josiah Carlson wrote:

Since PEP 310 was already mentioned, can we just say that the discussion
can be boiled down to different ways of spelling __enter__/__exit__ from
PEP 310?
It's not quite the same thing. PEP 310 suggests a mechanism
with a fixed control flow -- do something on entry, do the
code block, do something on exit. A general block-passing
mechanism would give complete control to the function as
to when and how to call the block.

I would like to ask a question.  Does Python want or need Ruby code
blocks?  I ask because that is what is being offered to cure what ails
us.  Don't get me wrong, I'm sure code blocks can solve quite a few
problems (and is used as such in Ruby), but I'm not convinced that it is
the solution for Python.
Any manual on Ruby will invariably discuss code blocks as one of the
most powerful features Ruby has to offer.  Sounds great.  Sounds like a
great big sledgehammer that can be used to do a bunch of things...so
what is currently being proposed as a use for them, and what can't they
do (that would be really nice)?
They are being offered, right now, as a setup and finalization mechanism. 
Essentially a way of allowing people to wrap their own blocks of code in
custom try/finally code, or whatever their minds can think up.  Ok,
__enter__/__exit__ offers that.  What else?

If you were to pass your generator as a code block, then you could
finalize a generator [1], and even raise exceptions in your code block,
but it still wouldn't allow one to pass exceptions into a currently
running generator (a long standing problem such that if we could, then
we would get generator finalization for free [2]).
What else?  Let's dig back into the python-dev archives...
http://mail.python.org/pipermail/python-dev/2003-February/032739.html
Guido:
- synchronized-like, where the block should connect to its environment
- property-like, where the block should introduce a new scope, and the
 caller should be able to inspect or control that scope's namespace

The synchronized-like thing is the custom try/finally, aka
__enter__/__exit__ as specified in PEP 310.
The property-like thing was perhaps to be an easier way to generate
properties, which fairly quickly fell to the wayside in discussion,
seemingly because people didn't see a need to add thunks for this.
Later XML DOM parsing came into the discussion, and was quickly
dismissed as being not possible due to the Python parser's limited
lookahead.
Someone else mentioned that thunks could be used to generate a switch
statement, but no elaboration was done, and no PEP was actually written
(switch has also had its own PEP, and even talk of a peephole
optimization for certain if/elif/else blocks to be made into dictionary
lookups...)

So where has all this reading gotten me?  To the point that I believe
previous discussion had concluded that Ruby-style code blocks have
little use in Python.  *shrug*
well, I think some people desire a more streamlined way of writing code
like:
def f(...)
...
def g(...)
...
x = h(...,f,g)
[property, setting up callbacks etc are cases of this]
were f,g etc definitions would appear inline and the whole has a
statement flavor; because this is Python a form that does not involve a
lot parantheses would be nice. Of course if the functions then are
allowed to change the surrounding bindings this could be used for
resource release issues etc.
Notice that decorators basically support a special case of this.
But yes, apart for the issue of rebinding (and if one wants non-local
returns), this is stricly about sugar.



___
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] thread semantics for file objects

[Samuele Pedroni]

Jeremy Hylton wrote:
On Thu, 17 Mar 2005 16:25:44 -0500, Aahz <[EMAIL PROTECTED]> wrote:
On Thu, Mar 17, 2005, Jeremy Hylton wrote:
Are the thread semantics for file objecst documented anywhere?  I
don't see anything in the library manual, which is where I expected to
find it.  It looks like read and write are atomic by virtue of fread
and fwrite being atomic.
Uncle Timmy will no doubt agree with me: the semantics don't matter.
NEVER, NEVER access the same file object from multiple threads, unless
you're using a lock.  And even using a lock is stupid.

I'm not looking for your permission or approval.  I just want to know
what semantics are intended.  If the documentation wants to say that
the semantics are undefined that okay, although I think we need to say
more because some behavior has been provided by the implementation for
a long time.
I think this is left unspecified for example by Java too. I would be 
surprised if Jython would offer the same characteristics in this respect 
as CPython.
___
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 instances of nested classes

[Samuele Pedroni]

Walter Dörwald wrote:
For XML: 1) Those classes are the element types and the nested classes
are the attributes. 2) Being able to define those attributes as separate
classes makes it possible to implement custom functionality (e.g. for
validation or for handling certain attribute types like URLs, colors etc.)
and 3) Those classes get instantiated when an XML tree is created or parsed.
A framework that does this (and my main motivation for writing this :)) is
XIST (see http://www.livinglogic.de/Python/xist/).
For the ORM case: Each top level class defines a table and the nested
classes are the fields, i.e. something like this:
class person(Table):
class firstname(Varchar):
"The person's first name"
null = False
class lastname(Varchar):
"The person's last name"
null = False
class password(Varchar):
"Login password"
def validate(self, value):
if not any(c.islower() for c in value) and \
   not any(c.isupper() for c in value) and \
   not any(c.isdigit() for c in value):
raise InvalidField("password requires a mix of upper 
and lower"
   "case letters and digits")
Instances of these classes are the records read from the database. A framework
that does something similar to this (although AFAIK fields are not nested
classes is SQLObject (http://sqlobject.org/)
So is this change wanted? useful? implementable with reasonable effort? Or
just not worth it?
notice that in this cases often metaclasses are involved or could easely 
be, so if pickling would honor __reduce__ or __reduce_ex__ on 
metaclasses (which right now it doesn't treating their instances as 
normal classes) one could roll her own solution without the burden for 
the language of implementing pickling of nested classes in general, so I 
think that would make more sense, to add support to honor 
__reduce__/__reduce_ex__ for metaclasses.


___
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 instances of nested classes

[Samuele Pedroni]

Walter Dörwald wrote:
Samuele Pedroni wrote:
Walter Dörwald wrote:
[User cases for pickling instances of nested classes]
So is this change wanted? useful? implementable with reasonable 
effort? Or
just not worth it?

notice that in this cases often metaclasses are involved or could 
easely be, so if pickling would honor __reduce__ or __reduce_ex__ on 
metaclasses (which right now it doesn't treating their instances as 
normal classes) one could roll her own solution without the burden for 
the language of implementing pickling of nested classes in general, so 
I think that would make more sense, to add support to honor 
__reduce__/__reduce_ex__ for metaclasses.

Sorry, I don't understand: In most cases it can be possible to
work around the nested classes problem by implementing custom pickling 
functionality (getstate/setstate/reduce/reduce_ex). But it is probably 
impossible to implement this once and for all in a common base class, 
because there's no way to find the real name of the nested class (or any 
other handle that makes it possible to retrieve the class from the 
module on unpickling).

And having the full name of the class available would certainly help in 
debugging.

that's probably the only plus point but the names would be confusing wrt
 modules vs. classes.
My point was that enabling reduce hooks at the metaclass level has
propably other interesting applications, is far less complicated than
your proposal to implement, it does not further complicate the notion of
what happens at class creation time, and indeed avoids the
implementation costs (for all python impls) of your proposal and still
allows fairly generic solutions to the problem at hand because the
solution can be formulated at the metaclass level.
If pickle.py is patched along these lines [*] (strawman impl, not much
tested but test_pickle.py still passes, needs further work to support
__reduce_ex__ and cPickle would need similar changes) then this example 
works:

class HierarchMeta(type):
  """metaclass such that inner classes know their outer class, with 
pickling support"""
  def __new__(cls, name, bases, dic):
  sub = [x for x in dic.values() if isinstance(x,HierarchMeta)]
  newtype = type.__new__(cls, name, bases, dic)
  for x in sub:
  x._outer_ = newtype
  return newtype

  def __reduce__(cls):
  if hasattr(cls, '_outer_'):
  return getattr, (cls._outer_, cls.__name__)
  else:
  return cls.__name__
# uses the HierarchMeta metaclass
class Elm:
  __metaclass__ = HierarchMeta
  def __init__(self, **stuff):
  self.__dict__.update(stuff)
  def __repr__(self):
  return "<%s %s>" % (self.__class__.__name__, self.__dict__)
# example
class X(Elm):
  class Y(Elm):
pass
  class Z(Elm):
pass
import pickle
x = X(a=1)
y = X.Y(b=2)
z = X.Z(c=3)
xs = pickle.dumps(x)
ys = pickle.dumps(y)
zs = pickle.dumps(z)
print pickle.loads(xs)
print pickle.loads(ys)
print pickle.loads(zs)
pedronis$ python2.4 example.py




[*]:
--- pickle.py.orig  Wed Mar 30 20:37:14 2005
+++ pickle.py   Thu Mar 31 21:09:41 2005
@@ -298,12 +298,19 @@
 issc = issubclass(t, TypeType)
 except TypeError: # t is not a class (old Boost; see SF #502085)
 issc = 0
+reduce = None
 if issc:
-self.save_global(obj)
-return
+for x in t.__mro__:
+if x is not object and '__reduce__' in x.__dict__:
+reduce = x.__dict__['__reduce__']
+break
+else:
+self.save_global(obj)
+return
 # Check copy_reg.dispatch_table
-reduce = dispatch_table.get(t)
+if not reduce:
+reduce = dispatch_table.get(t)
 if reduce:
 rv = reduce(obj)
 else:


___
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 instances of nested classes

[Samuele Pedroni]

Walter Dörwald wrote:
Samuele Pedroni wrote:
[...]
And having the full name of the class available would certainly help 
in debugging.

that's probably the only plus point but the names would be confusing wrt
 modules vs. classes.

You'd propably need a different separator in repr. XIST does this:
>>> from ll.xist.ns import html
>>> html.a.Attrs.href

My point was that enabling reduce hooks at the metaclass level has
propably other interesting applications, is far less complicated than
your proposal to implement, it does not further complicate the notion of
what happens at class creation time, and indeed avoids the
implementation costs (for all python impls) of your proposal and still
allows fairly generic solutions to the problem at hand because the
solution can be formulated at the metaclass level.

Pickling classes like objects (i.e. by using the pickling methods in 
their (meta-)classes) solves only the second part of the problem: 
Finding the nested classes in the module on unpickling. The other 
problem is to add additional info to the inner class, which gets 
pickled and makes it findable on unpickling.

If pickle.py is patched along these lines [*] (strawman impl, not much
tested but test_pickle.py still passes, needs further work to support
__reduce_ex__ and cPickle would need similar changes) then this 
example works:

class HierarchMeta(type):
  """metaclass such that inner classes know their outer class, with 
pickling support"""
  def __new__(cls, name, bases, dic):
  sub = [x for x in dic.values() if isinstance(x,HierarchMeta)]

I did something similar to this in XIST, but the problem with this 
approach is that in:

class Foo(Elm):
   pass
class Bar(Elm):
   Baz = Foo
the class Foo will get its _outer_ set to Bar although it shouldn't.
this should approximate that behavior better: [not tested]
  import sys
 
 def __new__(cls, name, bases, dic):
 sub = [x for x in dic.values() if isinstance(x,HierarchMeta)]
 newtype = type.__new__(cls, name, bases, dic)
 for x in sub:
 if not hasattr(x, '_outer_') and 
getattr(sys.modules.get(x.__module__), x.__name__, None) is not x:
  x._outer_ = newtype
 return newtype

 .
we don't set _outer_ if a way to pickle the class is already there
___
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] Security capabilities in Python

[Samuele Pedroni]

Ka-Ping Yee wrote:
On Sat, 9 Apr 2005, Jp Calderone wrote:
 Does using the gc module to bypass this security count?  If so:
   [EMAIL PROTECTED]:~$ python -i facet.py
   >>> import gc
   >>> c = readonly_facet.__getattr__.func_closure[1]
   >>> r = gc.get_referents(c)[0]
   >>> r.n = 'hax0r3d'
   >>> readonly_facet.value()
   'hax0r3d'
   >>>

You can't get func_closure in restricted mode.  (Or at least, i can't,
using the Python included with Mac OS 10.3.8.)
>>> restrict()
>>> readonly_facet.__getattr__.func_closure
Traceback (most recent call last):
  File "", line 1, in ?
RuntimeError: restricted attribute
>>>
Even though this particular example doesn't work in restricted mode,
it's true that the gc module violates capability discipline, and you
would have to forbid its import.  In any real use case, you would have
to restrict imports anyway to prevent access to sys.modules or loading
of arbitrary binaries.
For a version that restricts imports, see:
http://zesty.ca/python/facet.py
Let me know if you figure out how to defeat that.
you should probably search the list and look at my old attacks against
restricted execution, there's reason why is not much supported anymore.
One can still try to use it but needs to be extremely careful or use C 
defined proxies... etc.

(This is a fun exercise, but with a potential purpose -- it would be
nice to have a coherent story on this for Python 3000, or maybe even
Python 2.x.)
-- ?!ng
___
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/pedronis%40strakt.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: anonymous blocks

[Samuele Pedroni]

   def do():
   print "setup"
   try:
   yield None
   finally:
   print "tear down"
doesn't quite work (if it did, all you would need is syntactic sugar 
for "for
dummy in").

PEP325 is about that
___
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: switch statement

[Samuele Pedroni]

Michael Hudson wrote:
Shannon -jj Behrens <[EMAIL PROTECTED]> writes:
 

On 4/20/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
   

My use case for switch is that of a parser switching on tokens.
mxTextTools applications would greatly benefit from being able
to branch on tokens quickly. Currently, there's only callbacks,
dict-to-method branching or long if-elif-elif-...-elif-else.
 

I think "match" from Ocaml would be a much nicer addition to Python
than "switch" from C.
   

Can you post a quick summary of how you think this would work?
 

Well, Python lists are used more imperatively and are not made up with 
cons cells,
we have dictionaries which because of ordering issues are not trivial to 
match,
and  no general ordered records with labels. We have objects and not 
algebraic
data types. Literature on the topic usually indicates the visitor 
pattern as the
moral equivalent of pattern matching in an OO-context vs. algebraic data 
types/functional
one. I agree with that point of view and Python has idioms for the 
visitor pattern.

Interestingly even in the context of objects one can leverage the 
infrastructure that is
there for generalized copying/pickling to allow generalized pattern 
matching of
nested object data structures. Whether it is practical I don't know.

>>> class Pt:
...   def __init__(self, x,y):
... self.x = x
... self.y = y
...
>>> p(lambda _: Pt(1, _()) ).match(Pt(1,3))
(3,)
>>> p(lambda _: Pt(1, Pt(_(),_(.match(Pt(1,Pt(Pt(5,6),3)))
(<__main__.Pt instance at 0x40200b4c>, 3)
http://codespeak.net/svn/user/pedronis/match.py is an experiment in that 
direction (preceding this discussion
and inspired while reading a book that was using OCaml for its examples).

Notice that this is quite grossly subclassing pickling infrastracture  
(the innocent bystander should probably not try that), a cleaner 
approach redoing that logic with matching in mind is possible and would 
be preferable.






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

[Samuele Pedroni]

Fredrik Lundh wrote:
Regardless, I believe that solving generator finalization (calling all
enclosing finally blocks in the generator) is a worthwhile problem to
solve.  Whether that be by PEP 325, 288, 325+288, etc., that should be
discussed.  Whether people use it as a pseudo-block, or decide that
blocks are further worthwhile, I suppose we could wait and see.
   

Agreed.
 

I agree, in fact I think that solving that issue is very important 
before/if ever introducing a generalized block statement because otherwise
things that would naturally be expressible with for and generators will 
use the block construct which allow more variety and
so possibly less immediate clarity just because generators are not good 
at resource handling.
___
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

[Samuele Pedroni]

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;
and it bugs me that the finally clause's reachability depends on the
destructor executing.
yes, PEP325 would work in combination with PEP310, whether a combined 
thing (which cannot be the current for as dicussed) is desirable is a 
different issue: these anyway

f = file(...):
  for line in f:
...
vs.
it = gen():
  for val in it:
...
would be analogous in a PEP310+325 world.
___
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] defmacro (was: Anonymous blocks)

[Samuele Pedroni]

Michael Chermside wrote:
Jim Jewett writes:
 

As best I can tell, the anonymous blocks are used to take
care of boilerplate code without changing the scope -- exactly
what macros are used for.
   

Folks, I think that Jim is onto something here.
I've been following this conversation, and it sounds to me as if we
are stumbling about in the dark, trying to feel our way toward something
very useful and powerful. I think Jim is right, what we're feeling our
way toward is macros.
The problem, of course, is that Guido (and others!) are on record as
being opposed to adding macros to Python. (Even "good" macros... think
lisp, not cpp.) I am not quite sure that I am convinced by the argument,
but let me see if I can present it:
 Allowing macros in Python would enable individual programmers or
 groups to easily invent their own "syntax". Eventually, there would
 develop a large number of different Python "dialects" (as some
 claim has happened in the Lisp community) each dependent on macros
 the others lack. The most important casualty would be Python's
 great *readability*.
(If this is a strawman argument, i.e. if you know of a better reason
for keeping macros OUT of Python please speak up. Like I said, I've
never been completely convinced of it myself.)
 

The typical argument in defense of macros is that macros are just like 
functions, you go to the definition
and see what they does.

But depending on how much variation they offer over the normal grammar 
even eye parsing them may be difficult.

They make it easy to mix to code that is evaluated immediately and code 
that will be evalutated, maybe even repeatedely, later, each
macro having its own rules about this. In most cases the only way  to 
discern this and know what is what is indeed looking at the macro 
definition.

You can get flame wars about whether introducing slightly different 
variations of if is warranted. <.5 wink>

My personal impression is that average macro definitions (I'm thinking 
about Common Lisp or Dylan and similar) are much less
readable that average function definitions. Reading On Lisp may give an 
idea about this. That means that introducing macros in Python, because 
of the importance that readability has in Python, would need a serious 
design effort to make the macro definitions themself readable. I think 
that's a challenging design problem.

Also agree about the technical issues that Guido cited about referencing 
and when macros definition enter in effect etc.

___
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] defmacro (was: Anonymous blocks)

[Samuele Pedroni]

Robert Brewer wrote:
Shane Hathaway wrote:
Robert Brewer wrote:
So currently, all subclasses just override __set__, which leads to a
*lot* of duplication of code. If I could write the base 
class' __set__
to call "macros" like this:
   def __set__(self, unit, value):
   self.begin()
   if self.coerce:
   value = self.coerce(unit, value)
   oldvalue = unit._properties[self.key]
   if oldvalue != value:
   self.pre()
   unit._properties[self.key] = value
   self.post()
   self.end()
   defmacro begin:
   pass
   
   defmacro pre:
   pass
   
   defmacro post:
   pass
   
   defmacro end:
   pass
Here is a way to write that using anonymous blocks:
   def __set__(self, unit, value):
   with self.setting(unit, value):
   if self.coerce:
   value = self.coerce(unit, value)
   oldvalue = unit._properties[self.key]
   if oldvalue != value:
   with self.changing(oldvalue, value):
   unit._properties[self.key] = value
   def setting(self, unit, value):
# begin code goes here
   yield None
   # end code goes here
   def changing(self, oldvalue, newvalue):
   # pre code goes here
   yield None
   # post code goes here
...
Which do you prefer?  I like fewer methods. ;-)

I still prefer more methods, because my actual use-cases are more
complicated. Your solution would work for the specific case I gave, but
try factoring in:
* A subclass which needs to share locals between begin and post, instead
of pre and post.
or
* A set of 10 subclasses which need the same begin() but different end()
code.
Yielding seems both too restrictive and too inside-out to be readable,
IMO.

it seems what you are asking for are functions that are evaluated in 
namespace of the caller:

- this seems fragile, the only safe wat to implement 'begin' etc is to 
exactly know what goes on in __set__ and what names are used there

- if you throw in deferred evaluation for exprs or suites passed in
as arguments and even without considering that, it seems pretty horrid 
implementation-wise

Notice that even in Common Lisp you cannot really do this, you could 
define a macro that produce a definition for __set__ and takes fragments 
corresponding to begin ... etc


___
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

[Samuele Pedroni]

Michael Hudson wrote:
The history of iterators and generators could be summarized by saying 
that an API was invented, then it turned out that in practice one way 
of implementing them -- generators -- was almost universally useful.

This proposal seems a bit like an effort to make generators good at 
doing something that they aren't really intended -- or dare I say 
suited? -- for.  The tail wagging the dog so to speak.

it is fun because the two of us sort of already had this discussion in 
compressed form a lot of time ago:

http://groups-beta.google.com/groups?q=with+generators+pedronis&hl=en
not that I was really conviced about my idea at the time which was very 
embrional,  and in fact I'm bit skeptical right now about how much 
bending or not of generators makes sense, especially for a learnability 
point of view.
___
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

[Samuele Pedroni]

Jim Fulton wrote:
Duncan Booth wrote:
Jim Fulton <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:

Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some observations:
1. It looks to me like a bare return or a return with an EXPR3 that
happensto evaluate to None inside a block simply exits the 
block, rather
   than exiting a surrounding function. Did I miss something, or is
   this a bug?


No, the return sets a flag and raises StopIteration which should make 
the iterator also raise StopIteration at which point the real return 
happens.

Only if exc is not None
The only return in the pseudocode is inside "if exc is not None".
Is there another return that's not shown? ;)
I agree that we leave the block, but it doesn't look like we
leave the surrounding scope.
that we are having this discussion at all seems a signal that the 
semantics are likely too subtle.

___
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

[Samuele Pedroni]

Greg Ewing wrote:
Guido van Rossum wrote:
And surely you exaggerate.  How about this then:
The with-statement is similar to the for-loop.  Until you've
learned about the differences in detail, the only time you should
write a with-statement is when the documentation for the function
you are calling says you should.

I think perhaps I'm not expressing myself very well.
What I'm after is a high-level explanation that actually
tells people something useful, and *doesn't* cop out by
just saying "you're not experienced enough to understand
this yet".
this makes sense to me, also because a new control statement
will not be usually as hidden as metaclasses and some other possibly
obscure corners can be. OTOH I have the impression that the new toy is 
too shiny to have a lucid discussion whether it could have sharp edges 
or produce dizziness for the unexperienced.
___
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 Language track at Europython, still possibilities to submit talks

[Samuele Pedroni]

I'm the track chair of the Python Language track at Europython (27-29 
June, Göteborg, Sweden) . The general deadlline for talk submission has 
been extended until the 7th of May.

There are still open slots for the language track. So if someone with 
(core) language interests is or may be interested in partecipating, 
there's still the possibility to submit
talks about idioms, patterns, recent new additions to language (for 
example new 2.4 features), or other language related topics.

http://www.europython.org/sections/tracks_and_talks/propose_a_talk/#language
http://www.europython.org/sections/tracks_and_talks/propose_a_talk/
http://www.europython.org

Regards,

Samuele Pedroni, Python Language Track chair.

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

Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes

[Samuele Pedroni]

Almann T. Goo wrote:
>>As far as I remember, Guido wasn't particularly opposed
>>to the idea, but the discussion fizzled out after having
>>failed to reach a consensus on an obviously right way
>>to go about it.
> 
> 
> My apologies for bringing this debated topic again to the
> front-lines--that said, I think there has been good, constructive
> things said again and sometimes it doesn't hurt to kick up an old
> topic.  After pouring through some of the list archive threads and
> reading through this thread, it seems clear to me that the community
> doesn't seem all that keen on fixing issue--which was my goal to
> ferret out.
> 
> For me this is one of those things where the Pythonic thing to do is
> not so clear--and that mysterious, enigmatic definition of what it
> means to be Pythonic can be quite individual so I definitely don't
> want to waste my time arguing what that means.
> 
> The most compelling argument for not doing anything about it is that
> the use cases are probably not that many--that in itself makes me less
> apt to push much harder--especially since my pragmatic side agrees
> with a lot of what has been said to this regard.
> 
> IMO, Having properly nested scopes in Python in a sense made having
> closures a natural idiom to the language and part of its "user
> interface."  By not allowing the name re-binding it almost seems like
> that "user interface" has a rough edge that is almost too easy to get
> cut on.  This in-elegance seems very un-Pythonic to me.
> 

If you are looking for rough edges about nested scopes in Python
this is probably worse:

 >>> x = []
 >>> for i in range(10):
...   x.append(lambda : i)
...
 >>> [y() for y in x]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]

although experienced people can live with it. The fact is that
importing nested scope from the like of Scheme it was not considered
that in Scheme for example, looping constructs introduce new scopes.
So this work more as expected there. There were long threads
about this at some point too.

Idioms and features mostly never port straightforwardly from language
to language.

For example Python has nothing with the explicit context introduction
and grouping of a Scheme 'let', so is arguable that nested scope
code, especially with rebindings, would be less clear, readable than
in Scheme (tastes in parenthesis kept aside).




> Anyhow, good discussion.
> 
> Cheers,
> Almann
> 
> --
> Almann T. Goo
> [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/pedronis%40strakt.com

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

Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes

[Samuele Pedroni]

Greg Ewing wrote:
> Jeremy Hylton wrote:
> 
> 
>>The names of naming statements are quite hard to get right, I fear.
> 
> 
> My vote goes for 'outer'.
> 
> And if this gets accepted, remove 'global' in 3.0.
> 

In 3.0 we could remove 'global' even without 'outer',
and make module global scopes read-only, not rebindable
after the top-level code has run (i.e. more like function
body scopes). The only free-for-all namespaces would be
class and instance ones. I can think of some
gains from this.  <.3 wink>
___
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] Making builtins more efficient

[Samuele Pedroni]

Phillip J. Eby wrote:
> At 02:47 PM 3/13/2006 -0500, Jim Jewett wrote:
> 
>>Paul Moore wrote:
>>
>>
>>>Is there any practical way of detecting and flagging
>>>constructs like the above (remotely shadowing a
>>>builtin in another module)?
>>
>>Phillip J. Eby wrote:
>>
>>>the patch ended up being backed out ... too strict
>>>of a check to be accepted for Python 2.4.
>>
>>http://svn.python.org/view/python/trunk/Objects/moduleobject.c
>>
>>It was revision 33054, backed out in 33084.
>>
>>The patch warned about any shadowing of builtins, which
>>probably is too strict.
> 
> 
> I'm curious: what actually happened?  What things were causing warnings?

http://mail.python.org/pipermail/python-dev/2003-July/036879.html


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

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

Re: [Python-Dev] Threading idea -- exposing a global thread lock

[Samuele Pedroni]

Raymond Hettinger wrote:
>>it doesn't translate reasonably to Jython or IronPython, it's really tricky 
>>to 
>>implement,
> 
> 
> FWIW, someone on the newsgroup suggested implementing this via a slight 
> modification to sys.checkinterval().  The idea was that a None argument would 
> translate to "stop-checking" and the active thread would do a few steps 
> atomically and then restore the original value.  The new with-statement makes 
> that a piece of cake.
> 
>

there's no sys.checkinterval in Jython. Implementing this would need the
introduction of some kind of GIL implementation in Jython, the JVM has 
no primitive for global critical sections. A GIL is something users of 
Jython don't want. Even with that is way too easy to have non-Jython 
threads around that could manipulates Java objects you are seamlessy 
dealing with. That is of course true for CPython and C extension 
initiated threads too, but is probably harder to be oblivious
of such things in CPython context.
___
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] Threading idea -- exposing a global thread lock

[Samuele Pedroni]

Raymond Hettinger wrote:

> [Samuele Pedroni]
>
>> there's no sys.checkinterval in Jython. Implementing this would need the
>> introduction of some kind of GIL implementation in Jython, the JVM 
>> has no primitive for global critical sections.
>
>
> Wouldn't Java implement this directly by suspending and resuming the 
> other threads (being careful to avoid access to monitored resources 
> and to pair the suspend/resume operations in a try/finally or 
> with-statement to prevent deadlocks)?

suspending a thread is a deprecated operation because it can cause 
deadlocks.
___
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] GeneratorExit inheriting from Exception

[Samuele Pedroni]

Barry Warsaw wrote:
> On Sat, 2006-03-18 at 22:53 +1000, Nick Coghlan wrote:
> 
>>Should GeneratorExit inherit from Exception or BaseException?
> 
> 
> Actually, this prompts me to write about an issue I have with PEP 352.
> I actually don't think it's necessary (yes, I know it's already in the
> tree).
> 
> What I would much rather is is for StandardError to be renamed Error,
> for Exception to remain the base class of the exception hierarchy, and
> for KeyboardInterrupt to be moved to inherit directly from Exception.
> GeneratorExit, SystemExit, and StopIteration would continue to inherit
> from Exception.
> 
> The reasoning is this: anything that can be raised is an Exception.  Not
> all Exceptions are Errors.  Anything that signals an error condition is
> an Error, and anything that signals a warning condition is a Warning.
> Thus the basic hierarchy /ought/ to be:
> 
> Exception
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> |  +- ImportError
> |  +- (etc.)
> |
> +- Warning
>+- UserWarning
>+- (etc.)
> 
> Use defined errors should inherit from Error, not Exception.  With this,
> "except Exception" would be a synonym for bare except, while "except
> Error" would be the standard idiom for letting non-error exceptions pass
> through.
> 
> I don't know whether this is possible for Python 2.5, 

well, one thing to consider is all the

class MyException(Exception):

in current code.


> but I think it
> should be what we strive for for Py3K, and I do not think BaseException
> is at all necessary.
> 
> -Barry
> 
> 
> 
> 
> 
> ___
> 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/pedronis%40strakt.com

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

[Python-Dev] Next PyPy Sprint: Tokyo 23/4 - 29/4

[Samuele Pedroni]

Tokyo PyPy Sprint: 23rd - 29th April 2006


The next PyPy sprint is scheduled to take place 23rd- 29th April 2006
(Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with
FSIJ (Free Software Initiative of Japan) aim to promote Python and
PyPy.  We therefor invite Japanese hackers knowledgeable in Python to
join our sprint!  We'll give newcomer-friendly introductions. To learn
more about the new Python-in-Python implementation look here:

 http://codespeak.net/pypy

For this sprint we are particularly interested in meeting and coding on
PyPy together
with interested Japanese Python hackers. Please register your interest
at [EMAIL PROTECTED]
as soon as possible and we will help with any questions regarding
getting started, pointing
to relevant documentation etc.

The PyPy team is curious and interested in the experience of hacking
code for embedded devices
and would love to discuss and get feedback on optimisation efforts and
the current state of PyPy.

Goals and topics of the sprint
--

Possible suggestions for topics are:

   - Work on gensqueak (our Squeak backend) or possibly other backends.

   - Implementing Python 2.5 features in PyPy.

   - Progress further on an 'rctypes' module aiming at letting us use a
ctypes
 implementation of an extension module from the compiled pypy-c.

   - Writing ctypes implementations of modules to be used by the above
 tool.

   - Experimenting and improving performance of our garbage collectors.

   - Experiment with PyPy flexibility or other aspects of the
implementation.

   - Possibly experiment with writing modules translatable for use both
 in PyPy and CPython.

   - Whatever participants want to do with PyPy or particular areas
 of PyPy (please send suggestions to the mailing list before to
allow us to plan
 and give feedback)


Location & Accomodation


The sprint will be held at National Institute of AIST
  (National Institute of Advanced Industrial Science and Technology,
  http://www.aist.go.jp/index_en.html), Akihahabara (the technical gadget
district in Tokyo). Yutaka Niibe is our contact person there,
helping with arranging facilities. Niibe is the chairman of FSIJ and
they have
invited us to sprint in Tokyo and we are very grateful for the help and
interest
we have recieved so far.

The facilities we are sprinting in are located here:

 http://www.gtrc.aist.go.jp/en/access/index.html#Akihabara


The actual address is:
Akihabara Dai Bldg , 1-18-13 Sotokanda, Chiyoda-ku, Tokyo 101-0021 Japan
Phone: +81-3-5298-4729

Hotel areas - we are recommended to book hotels in Ueno and Asakusa (old
town),
from those areas there are only two metro stops to Akihabara. Please
note that
hotelrooms in Tokyo are often very small.

 http://www.wh-rsv.com/english/akihabara/index.html  (nearest
hotel to sprint location)
 http://www.greenhotel.co.jp/ochanomizu_e.html
 http://www.ohgai.co.jp/index-e.html (Ueno)
 http://www.toyoko-inn.com/e_hotel/00012/index.html (Asakusa)
 http://www.hotelnewkanda.com/   (second nearest, but no english
page)

Here is a url for booking hotels with not too unreasonable rates (see map):
http://japan-hotelguide.com/hotels/Japan/Tokyo/index.htm

For more general tourist information about travelling to Japan and Tokyo
- please see:
http://www.jnto.go.jp/eng/
http://www.japantravelinfo.com/  (really useful information regarding
airfares, hotels, currency, phones etc etc)

Comments on the weather: In end April it is ca 20 degrees Celsius.


Exact times
---

The public PyPy sprint is held Sunday 23rd - Saturday 29th April 2006.
Hours will be from 10:00 until people have had enough.  It's a good idea
to arrive a day before the sprint starts and leave a day later.
Sometimes people
cannot stay for the whole sprint - you are welcome even if you can only stay
for a day or a few days.

Sunday: Starting at 10:00. This day is focused on getting to know PyPy
enought to
start to participate. We will hold a PyPy tutorial and an architectural
overview.
Planning meeting for the work to be done during the week and grouping of
developers (pairs
or groups mixing new participants with core developers).

Dinner in the evening (Yutaka will arrange a place for us to go to).

Monday-Tuesday: Starting at 10:00 with status meetings. Possible regrouping
depending on the interest and progress of the various teams.

Wednesday: Breakday (coding is allowed although we recommend taking a
break).

Thursday-Saturday: Starting at 10:00 with status meetings. Possible
regrouping
depending on the interest and progress of the various teams. Ending on
Saturday with
a Closure session - summing of the work and planning work to be done
until the next sprint.


Network, Food, currency


We will have access to WiFi at AIST - please make sure you have wlan
capabilities.

Electric

Re: [Python-Dev] Class decorators

[Samuele Pedroni]

Mike Krell wrote:

>Greg Ewing  canterbury.ac.nz> writes:
>
>  
>
>>I've just been playing around with metaclasses, and
>>I think I've stumbled across a reason for having
>>class decorators as an alternative to metaclasses
>>for some purposes.
>>
>>
>
>There has also been discussion on the IronPython mailing list that class
>decorators would be a very useful syntax for expressing .NET attributes.  
>
>http://lists.ironpython.com/pipermail/users-ironpython.com/2006-March/002007.html
> 
>  
>
the same is true for Jython and Java annotations.
___
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] Reminder: call for proposals "Python Language and Libraries Track" for Europython 2006

[Samuele Pedroni]

"""
Python Language and Libraries

A track about Python the Language, all batteries included. Talks about 
the language, language evolution, patterns and idioms, implementations 
(CPython, IronPython, Jython, PyPy ...) and implementation issues belong 
to the track. So do talks about the standard library or interesting 
3rd-party libraries (and frameworks), unless the gravitational pull of 
other tracks is stronger.
"""

Of course talks to detail new features in the upcoming 2.5 release are 
more than welcome.

Deadline is 31th of May.

The full call and submission links are at:

http://www.europython.org/sections/tracks_and_talks/call-for-proposals

Thanks, Samuele Pedroni
___
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] Reminder: call for proposals "Python Language and Libraries Track" for Europython 2006

[Samuele Pedroni]

Registration for Europython (3-5 July) at CERN in Geneva is now open,
if you feel submitting a talk proposal there's still time until
the 31th of May.

If you want to talk about a library you developed, or you know well
and want to share your knowledge, or about how you are making the best
out of Python through inventive/elegant idioms and patterns (or if you
are a language guru willing to disseminate your wisdom),

you can submit a proposal for the Python Language and Libraries
track

"""

A track about Python the Language, all batteries included. Talks about
the language, language evolution, patterns and idioms, implementations
(CPython, IronPython, Jython, PyPy ...) and implementation issues belong
to the track. So do talks about the standard library or interesting
3rd-party libraries (and frameworks), unless the gravitational pull of
other tracks is stronger.
"""

The full call and submission links are at:

http://www.europython.org/sections/tracks_and_talks/call-for-proposals

Samuele Pedroni, Python Language and Libraries Track Chair

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

[Samuele Pedroni]

Fabio Zadrozny wrote:
> Python and Jython import semantics differ on how sub-packages should be 
> accessed after importing some module:
> 
> Jython 2.1 on java1.5.0 (JIT: null)
> Type "copyright", "credits" or "license" for more information.
>  >>> import xml
>  >>> xml.dom
> 
> 
> Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on 
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import xml
>  >>> xml.dom
> Traceback (most recent call last):
>   File "", line 1, in ?
> AttributeError: 'module' object has no attribute 'dom'
>  >>> from xml.dom import pulldom
>  >>> xml.dom
> 
> 
> Note that in Jython importing a module makes all subpackages beneath it 
> available, whereas in python, only the tokens available in __init__.py 
> are accessible, but if you do load the module later even if not getting 
> it directly into the namespace, it gets accessible too -- this seems 
> more like something unexpected to me -- I would expect it to be 
> available only if I did some "import xml.dom" at some point.
> 
> My problem is that in Pydev, in static analysis, I would only get the 
> tokens available for actually imported modules, but that's not true for 
> Jython, and I'm not sure if the current behaviour in Python was expected.
> 
> So... which would be the right semantics for this?

the difference in Jython is deliberate. I think the reason was to mimic 
more the Java style for this, in java fully qualified names always work. 
In jython importing the top level packages is enough to get a similar 
effect.

This is unlikely to change for backward compatibility reasons, at least 
from my POV.


> 
> Thanks,
> 
> Fabio
> 
> 
> 
> 
> ___
> 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/pedronis%40strakt.com

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

Re: [Python-Dev] Import semantics

[Samuele Pedroni]

Bill Janssen wrote:
>>the difference in Jython is deliberate. I think the reason was to mimic 
>>more the Java style for this, in java fully qualified names always work. 
>>In jython importing the top level packages is enough to get a similar 
>>effect.
>>
>>This is unlikely to change for backward compatibility reasons, at least 
>>from my POV.
> 
> 
> While I appreciate the usage concerns, at some point someone has to
> decide whether Jython is an implementation of Python, or a version of
> BeanShell with odd syntax. 

this is mildy insulting, to the people that spent time trying to find 
the best compromises between various issues and keep jython alive.
For example, I spent quite some energy at times to justify not 
implementing some unpythonic but tempting features from a java pov.

> If it's Python, it has to comply with the
> Python specification, regardless of what Java does.  

cpython cannot import java packages. also python rules don't translate
completely to them, and sometimes python import semantics are as clear 
as mud and reading import.c is the only way to know. Of course allowing 
this for python packages was an overgeneralisation.

> If it doesn't do
> that, it should be cast into the outer darkness of the Python world.
> 

this is a design decision that originates back to Jim. It could be 
limited maybe to java packages, but is sadly quite addictive.
That's why I mentionted a backward compatibility problem.


> The escape hatch here would be to redefine the Python specification to
> allow either behavior.
> 
> Bill

___
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] doc for new restricted execution design for Python

[Samuele Pedroni]

Brett Cannon wrote:
> 
> I don't know how JavaScript is doing it yet.  The critical thing for me 
> for this month was trying to come up with a security model.
> 
> And if you don't think it is going to scale, how do you think it should 
> be done?

if I remember correctly, the boundary/granularity of mutual isolation
is practically web domains, pages from the same domain can liberally 
access each other data, javascript state.
___
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] Import semantics

[Samuele Pedroni]

Frank Wierzbicki wrote:
> On 7/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> 
>>Hi Frank,
>>
>>Have you and/or the Jython community made up your mind about this? The
>>thread seems to have disappeared after you posted (or perhaps it
>>continued only on jython-dev, which I don't read?).
> 
> The thread pretty much stopped there.  I think a modification of the
> import semantics won't really come up again until 2.3 is out, since
> releases and reviving Jython take priority over backwards incompatible
> features.  For my part I would like to think that a goal for Jython
> should be:
> 
> Pure Python code developed first on Jython should run without change on 
> CPython.
> 
> Which would mean we will eventually need to change the import
> semantics for importing Python code (though I doubt we will change the
> semantics for importing Java packages any time soon).  Whether that
> can be done in 2.x, or if this change is so incompatible that we need
> to think about it in a "Jython 3000" way, I don't really know.

Changing the behavior of getattr for python modules and leave it as it 
is for java packages seems a reasonable compromise.


> 
> 
>>Also, I just realized that you're the new Jython maintainer. Is *that*
>>official?
> 
> It is official, at least in the unofficial way that Jython appears to
> work: Brian handed the baton to me after (I presume) Samuele Pedroni
> had handed the baton to Brian.
> 
> Brian's email is here:
> http://sourceforge.net/mailarchive/message.php?msg_id=13859029
> 
> That said, I still regard Samuele Pedroni as the ultimate authority on
> Jython and give him pretty much full veto power.  He fortunately
> continues to watch the checkins and prods me when I go in the wrong
> direction.
> 

as things stand this a reasonable way to go about things, I'm the only 
person with a bit historical prospective, a bit of time to help
(less than I would like still), knowing both python semantics well
and Java and knowing the Jython code base, also I designed how
the new-style classes implemantion work in Jython atm, so I should know
how things are supposed to hang together in that respect, also for 
things that involve the Java glueing aspects of Jython one needs
to grow some language design experience and sense, and I'm around since
enough time for Jython and on python-dev to have some of that :)

regards.

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

[Python-Dev] Next PyPy sprint: Heidelberg (Germany), 22nd-29th of August

[Samuele Pedroni]

PyPy Sprint in Heidelberg 22nd - 29th August 2005
==

The next PyPy sprint will take place at the Heidelberg University
in Germany from 22nd August to 29th August (both days included).
Its main focus is translation of the whole PyPy interpreter
to a low level language and reaching 2.4.1 Python compliancy.
To learn more about the new PyPy Python implementation
look here:

 http://codespeak.net/pypy


Goals and topics of the sprint
--

One of the main goals of the sprint is going to be a 0.7 release of
PyPy. The 0.7 is meant to be the first self-contained PyPy version but
still alpha with some C-extension modules missing and not meant for
production use.

Therefore the topics of the sprint will be:

- translation efforts: it's not completely clear now what related
  task will be left at that time
- work on 2.4.1 compliancy: there are some failing compliancy tests
  on which we plan to work
- rewriting c-extension modules/integrating existing rewrites
- all kinds of small release issues
- possibly some more LLVM efforts


Location & Accomodation


The sprint will be held in a conference room of the Institute of
Physics, University of Heidelberg. We have WLAN connection there and
small kitchen to make tea and coffee. `See here`_ how to get there from
the Heidelberg main station.

There is a huge number of hotels_ in Heidelberg, all of which are
unfortunately rather expensive. It should be no problem to reach the
sprint venue from anywhere in Heidelberg. As an alternative you could
also take a `hotel in Mannheim`_ which you can reach in 15 min from
Heidelberg with the train.

.. _`See here`:
http://www.physi.uni-heidelberg.de/physi/front/anfahrt.en.php
.. _hotels: http://www.cvb-heidelberg.de/index_eng.html
.. _`hotel in Mannheim`: http://www.hotels.de/en/mannheim.htm

Exact times
---

The Pypy sprint is held Monday 22nd August - Monday 29th August 2005.
Hours will be from 09:00 until people have had enough. It's a good
idea to arrive a day before the sprint starts.


Network, Food
-

The Heidelberg Altstadt can be reached in approximately 10 min from the
sprint venue. There you will find all kinds of restaurants and fast food
places.

You will probably need a wireless network card to access the network
although we could set up a WLAN to cable bridge if necessary.


Registration etc.pp.


Please subscribe to the `PyPy sprint mailing list`_, introduce
yourself and post a note that you want to come.  Feel free
to ask any questions there!  There also is a separate
`Heidelberg people`_ page tracking who is already thought
to come.  If you have commit rights on codespeak then
you can modify yourself a checkout of


http://codespeak.net/svn/pypy/extradoc/sprintinfo/heidelberg-people.txt

.. _`Heidelberg people`:
http://codespeak.net/pypy/index.cgi?extradoc/sprintinfo/heidelberg-people.html 


.. _`PyPy sprint mailing list`:
http://codespeak.net/mailman/listinfo/pypy-sprint

--
Samuele Pedroni & the PyPy team
___
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] __traceback__ and reference cycles

[Samuele Pedroni]

Tim Peters wrote:
> 
> I can't think of a Python feature with a higher aggregate
> braincell_burned / benefit ratio than __del__ methods.  If P3K retains
> them-- or maybe even before --we should consider taking "the Java
> dodge" on this one.  That is, decree that henceforth a __del__ method
> will get invoked by magic at most once on any given object O, no
> matter how often O is resurrected.
> 

Jython __del__ support is already layered on Java finalize, so that's
what one gets.
___
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 builtin id (and moving it to sys())

[Samuele Pedroni]

Jeremy Hylton wrote:
> I'd like to see the builtin id() removed so that I can use it as a
> local variable name without clashing with the builtin name.  I
> certainly use the id() function, but not as often as I have a local
> variable I'd like to name id.  The sys module seems like a natural
> place to put id(), since it is exposing something about the
> implementation of Python rather than something about the language; the
> language offers the is operator to check ids.
> 

it is worth to remember that id() functionality is not cheap for Python
impls using moving GCs. Identity mappings would be less taxing.

> Jeremy
> ___
> 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/pedronis%40strakt.com

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

Re: [Python-Dev] [Jython-dev] Re: AST branch is in?

[Samuele Pedroni]

Frank Wierzbicki wrote:
> On 10/20/05, *Neal Norwitz* <[EMAIL PROTECTED] 
> > wrote:
> 
> The Grammar is (was at one point at least) shared between Jython and
> would allow more tools to be able to share infrastructure.  The idea
> is to eventually be able to have [JP]ython output the same AST to
> tools.
> 
> 
> Hello Python-dev,
> 
> My name is Frank Wierzbicki and I'm working on the Jython project.  Does 
> anyone on this list know more about the history of this Grammar sharing 
> between the two projects?  I've heard about some Grammar sharing between 
> Jython and Python, and I've noticed that (most of) the jython code in 
> /org/python/parser/ast is commented "Autogenerated AST node".  I would 
> definitely like to look at (eventually) coordinating with this effort.
> 
> I've cross-posted to the Jython-dev list in case someone there has some 
> insight.

as far as I understand now Python trunk contains some generated AST
representation C code created through the asdl_c.py script from an 
updated Python.asdl, these files live in

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Parser/

a parallel asdl_java.py existed in Python CVS sandbox (where the
AST effort started) and was updated the last time the Jython
own AST classes were generated with at the time version of Python.asdl
(this was done by me if I remember correctly at some point in Jython
2.2 evolution, I think when the PyDev guys wanted a more up-to-date
Jython parser to reuse):

http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/nondist/sandbox/ast/asdl_java.py?content-type=text%2Fplain&rev=1.7

basically the new Python.asdl needs to be used, the asdl_java.py
maybe updated and our compiler changed as necessary.

regards.








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

Re: [Python-Dev] AST branch is in?

[Samuele Pedroni]

Guido van Rossum wrote:
> On 10/25/05, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
> 
>> My name is Frank Wierzbicki and I'm working on the Jython project.  Does
>>anyone on this list know more about the history of this Grammar sharing
>>between the two projects?  I've heard about some Grammar sharing between
>>Jython and Python, and I've noticed that (most of) the jython code in
>>/org/python/parser/ast is commented "Autogenerated AST node".  I would
>>definitely like to look at (eventually) coordinating with this effort.
>>
>> I've cross-posted to the Jython-dev list in case someone there has some
>>insight.
> 
> 
> Your best bet is to track down Jim Hugunin and see if he remembers.
> He's jimhug at microsoft.com or jim at hugunin.net.
> 

no. this is all after Jim, its indeed a derived effort from the CPython
own AST effort, just that we started using it quite a while ago.
This is all after Jim was not involved with Jython anymore, Finn Bock
started this.
___
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 different kind of reduce...

[Samuele Pedroni]

Reinhold Birkenfeld wrote:
> Raymond Hettinger wrote:
> 
>>[Martin Blais]
>>
I'm always--literally every time-- looking for a more functional
>>
>>form,
>>
something that would be like this:

   # apply dirname() 3 times on its results, initializing with p
   ... = repapply(dirname, 3, p)
>>
>>[Greg Ewing]
>>
>>>Maybe ** should be defined for functions so that you
>>>could do things like
>>>
>>>   up3levels = dirname ** 3
>>
>>Hmm, using the function's own namespace is an interesting idea.  It
>>might also be a good place to put other functionals:
>>
>>   results = f.map(data)
>>   newf = f.partial(somearg)
> 
> 
> And we have solved the "map, filter and reduce are going away! Let's all
> weep together" problem with one strike!

not really, those right now work with any callable,

 >>> class C:
...   def __call__(self, x):
... return 2*x
...
 >>> map(C(), [1,2,3])
[2, 4, 6]


that's why attaching functionaliy as methods is not always the best 
solution.

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

Re: [Python-Dev] Why should the default hash(x) == id(x)?

[Samuele Pedroni]

Noam Raphael wrote:
> On 11/5/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> 
>>More generally, I claim that the current behaviour is better than
>>*any* alternative. To refute this claim, you would have to come
>>up with an alternative first.
>>
> 
> The alternative is to drop the __hash__ method of user-defined classes
> (as Guido already decided to do), and to make the default __eq__
> method compare the two objects' __dict__ and slot members.
> 

no, whether object has an __hash__ and what is the default hashing
are different issues. Also all this discussion should have started and
lived on comp.lang.python and this is a good point as any to rectify this.


> See the thread about default equality operator - Josiah Carlson posted
> there a metaclass implementing this equality operator.
> 
> Noam
> ___
> 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/pedronis%40strakt.com

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

Re: [Python-Dev] For Python 3k, drop default/implicit hash, and comparison

[Samuele Pedroni]

Noam Raphael wrote:
> Three weeks ago, I read this and thought, "well, you have two options
> for a default comparison, one based on identity and one on value, both
> are useful sometimes and Guido prefers identity, and it's OK." But
> today I understood that I still think otherwise.
> 

well, this still belongs to comp.lang.python.

> In two sentences: sometimes you wish to compare objects according to
> "identity", and sometimes you wish to compare objects according to
> "values". Identity-based comparison is done by the "is" operator;
> Value-based comparison should be done by the == operator.
> 
> Let's take the car example, and expand it a bit. Let's say wheels have
> attributes - say, diameter and manufacturer. Let's say those can't
> change (which is reasonable), to make wheels hashable. There are two
> ways to compare wheels: by value and by identity. Two wheels may have
> the same value, that is, they have the same diameter and were created
> by the same manufacturer. Two wheels may have the same identity, that
> is, they are actually the same wheel.
> 
> We may want to compare wheels based on value, for example to make sure
> that all the car's wheels fit together nicely: assert car.wheel1 ==
> car.wheel2 == car.wheel3 == car.wheel4. We may want to compare wheels
> based on identity, for example to make sure that we actually bought
> four wheels in order to assemble the car: assert car.wheel1 is not
> car.wheel2 and car.wheel3 is not car.wheel1 and car.wheel3 is not
> car.wheel2...
> 
> We may want to associate values with wheels based on their values. For
> example, it's reasonable to suppose that the price of every wheel of
> the same model is the same. In that case, we'll write: price[wheel] =
> 25. We may want to associate values with wheels based on their
> identities. For example, we may want to note that a specific wheel is
> broken. For this, I'll first define a general class (I defined it
> before in one of the discussions, that's because I believe it's
> useful):
> 
> class Ref(object):
> def __init__(self, obj):
> self._obj = obj
> def __call__(self):
> return self._obj
> def __eq__(self, other):
> return isinstance(other, ref) and self._obj is other._obj
> def __hash__(self):
> return id(self._obj) ^ 0xBEEF
> 
> Now again, how will we say that a specific wheel is broken? Like this:
> 
> broken[Ref(wheel)] = True
> 
> Note that the Ref class also allows us to group wheels of the same
> kind in a set, regardless of their __hash__ method.
> 
> I think that most objects, especially most user-defined objects, have
> a *value*. I don't have an exact definition, but a hint is that two
> objects that were created in the same way have the same value.
> Sometimes we wish to compare objects based on their identity - in
> those cases we use the "is" operator. Sometimes we wish to compare
> objects based on their value - and that's what the == operator is for.
> Sometimes we wish to use the value of objects as a dictionary key or
> as a set member, and that's easy. Sometimes we wish to use the
> identity of objects as a dictionary key or as a set member - and I
> claim that we should do that by using the Ref class, whose *value* is
> the object's *identity*, or by using a dict/set subclass, and not by
> misusing the __hash__ and __eq__ methods.
> 
> I think that whenever value-based comparison is meaningful, the __eq__
> and __hash__ should be value-based. Treating objects by identity
> should be done explicitly, by the one who uses the objects, by using
> the "is" operator or the Ref class. It should not be the job of the
> object to decide which method (value or identity) is more useful - it
> should allow the user to use both methods, by defining __eq__ and
> __hash__ based on value.
> 
> Please give me examples which prove me wrong. I currently think that
> the only objects for whom value-based comparison is not meaningful,
> are objects which represent entities which are "outside" of the
> process, or in other words, entities which are not "computational".
> This includes files, sockets, possibly user-interface objects,
> loggers, etc. I think that objects that represent purely "data", have
> a "value" that they can be compared according to. Even wheels that
> don't have any attributes are simply equal to other wheels, and not
> equal to other objects. Since user-defined classes can interact with
> the "environment" only through other objects or functions, it  is
> reasonable to suggest that they should get a value-based equality
> operator. Many times the value is defined by the __dict__ and
> __slots__ members, so it seems to me a reasonable default.
> 
> I would greatly appreciate repliers that find a tiny bit of reason in
> what I said (even if they don't agree), and not deny it all as a
> complete load of rubbish.
> 

not if you think python-dev is a forum for such discussions
on OO thinking vs other paradigms.


> Thanks,
> Noam
> 

[Python-Dev] Next PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006

[Samuele Pedroni]

Palma de Mallorca  PyPy Sprint: 23rd - 29th January 2006





The next PyPy sprint is scheduled to take place January 2006 in

Palma De Mallorca, Balearic Isles, Spain. We'll give newcomer-friendly

introductions and the focus will mainly be on current JIT work, garbage

collection, alternative threading models, logic programming and on

improving the interface with external functions. To learn more about the

new Python-in-Python implementation look here:



 http://codespeak.net/pypy



Goals and topics of the sprint

--



In Gothenburg we have made some first forays into the interesting topics

of Just-in-Time compilation. In Mallorca we will continue that

and have the following ideas:



   - Further work/experimentation toward Just-In-Time Compiler generation,

 which was initiated with the Abstract Interpreter started in
Gothenburg.



   - Integrating our garbage collection toolkit with the backends and the

 code generation.



   - Heading into the direction of adding logic programming to PyPy.



   - Optimization work: our threading implementation is still incredibly

 slow, we need to work on that. Furthermore there are still quite

 some slow places in the interpreter that could be improved.



   - getting the socket module to a more complete state (it is

 already improved but still far from complete)



   - generally improving the way we interface with external functions.



   - whatever participants want to do with PyPy (please send

 suggestions to the mailing list before to allow us to plan

 and give feedback)





Location & Accomodation





The sprint will be held at the Palma University (UIB - Universitat de

les Illes Balears), in their GNU/Linux lab

(http://mnm.uib.es/phpwiki/AulaLinux).  We are hosted by the Computer

Science department and Ricardo Galli is our contact person there,

helping with arranging facilities.



The University is located 7 km away from the central Palma. Busses to

the University departs from "Plaza de España" (which is a very central

location in Palma). Take bus 19 to the UIB campus.  A ticket for one

urban trip costs 1 euro. You can also buy a card that is valid for 10

trips and costs 7.51 euros.  Information about bus timetables and routes

can be found on:



 http://www.a-palma.es



A map over the UIB campus are can be found on:



 http://www.uib.es/imagenes/planoCampus.html



The actual address is: 3r pis de l'Anselm Turmeda which can be found on

the UIB Campus map.



At "Plaza de España" there is a hostel (Hostal Residencia Terminus)

which has been recommended to us. It's cheap (ca 50 euros/double room

with bathroom). Some more links to accomodations (flats, student homes

and hotels):



http://www.lodging-in-spain.com/hotel/town/Islas_Baleares,Mallorca,Palma_de_Mallorca,1/



http://www.uib.es/fuguib/residencia/english/index.html



http://www.homelidays.com/EN-Holidays-Rental/110_Search/SearchList.asp?DESTINATION=Palma%20de%20Mallorca&ADR_PAYS=ES&ADR_

LOCALISATION=ES%20ISLASBALEARES%20MALLORCA



If you want to find a given street, you can search here:



 http://www.callejeando.com/Pueblos/pueblo7_1.htm



To get to Palma De Mallorca almost all low fare airlines and travel

agencies have cheap tickets to get there. Information about Mallorca and

Palma (maps, tourist information, local transports, recommended air

lines, ferries and much more) can be found on:



 http://www.palmademallorca.es/portalPalma/home.jsp



Comments on the weather: In January it is cold and wet on Mallorca



Average temperature: 8,4 degrees Celsius

Lowest temperature: 2 degrees Celsius

Highest temperature: 14,5 degrees Celsius

Average humidity rate: 77,6 %



So more time for coding and less time for sunbathing and beaches ;-)



Exact times

---



The public PyPy sprint is held Monday 23rd - Sunday 29th January 2006.

Hours will be from 10:00 until people have had enough.  It's a good idea

to arrive a day before the sprint starts and leave a day later.  In the

middle of the sprint there usually is a break day and it's usually ok to

take half-days off if you feel like it.



For this particular break day, Thursday, we are invited to the studio of

Ginés Quiñonero, a local artist and painter. Ginés have also been the

person helping us getting connections to UIB and providing much

appreciated help regarding accommodation and other logistical

information.



For those of you interested - here is his website where there also are

paintings showing his studio:



 http://www.hermetex4.com/damnans/



For those interested in playing collectable card games, this will also

be an opportunity to get aquainted with V:TES which will be demoed by

Ginés and Beatrice and Sten Düring. For more information on this

cardgame - see: http://www.white-wolf.com/vtes/index.php.  (The Mallorca

Re: [Python-Dev] status of development documentation

[Samuele Pedroni]

Tim Peters wrote:
> [Neal]
> 
>>Hmmm, I thought others were running the tests on Windows too.  There
>>was one report on Nov 22 about running Purify on Windows 2k (subject:
>>ast status, memory leaks, etc).  He had problems with a stack overflow
>>in test_compile.  He was going to disable the test and re-run.  I
>>never heard back though.  Based on that info, I would guess that
>>test_builtin was working on Win 2k on Nov 22.
> 
> 
> I wouldn't assume that.  My "nobody" was wrt the universe of Python
> developers, not users; folks like Trent and MarkH and you and me. 
> Without "normal" baseline test experience, users don't understand what
> they're seeing, and so their reports can be highly misleading.  You
> can trust that while I don't understand what I'm seeing here either,
> at least I told the absolute truth about it and didn't hold back
> critical details ;-)
> 
> That said, I was hoping to do some Python work over Thanksgiving week,
> but was mortally discouraged on the Nov 19-20 weekend by all the test
> failures I saw.  So I'm pretty sure (but not certain) that
> test_builtin was failing then.
> 
> 
>>>(A parenthentical question:  is there a reason you don't pass -uall to
>>>regrtest.py?)
> 
> 
>>It's calling make test.  I thought about calling regrtest.py instead
>>and doing as you suggest.  Is there a benefit to running make test?
> 
> 
> You're asking a Windows guy about make:  bad career move ;-)
> 
> 
>>I know it runs with and without -O.  I guess it's only machine time, I
>>could run make test and regrtest.py -uall.
> 
> 
> -uall is helpful in finding bugs.  One thing in particular here is
> that test_compiler runs only a tiny subset of its full test unless an
> appropriate -u flag is given.
> 
> 
>>>On WinXP Pro SP2 today, passing -uall, and after fixing all the MS
>>>compiler warnings that have crept in:
>>>
>>>251 tests OK.
>>>12 tests failed:
>>>test_builtin test_coding test_compiler test_pep263
>>>test_univnewlines test_urllib test_urllib2 test_urllibnet
>>>test_userlist test_wave test_whichdb test_zipfile
>>>1 skip unexpected on win32:
>>>test_xml_etree_c
> 
> 
>>Ouch!  I'm might be to blame for at least some of those. :-(
> 
> 
> I'm sure it's not as bad as it looks.  For example, test_coding and
> (the -uall) test_compiler fail for exactly the same reason.  For
> another, when a test fails on Windows, it sometimes leaves a "@test"
> file or directory behind, which causes a cascade of bogus failures
> later.  For example, test_userlist, test_wave, test_whichdb, and
> test_zipfile all pass when run alone here.  Others probably do too.
> 
> ...
> 
>>Do you know if the tests were broken before the AST merge (about Oct
>>22 I think)?
> 
> 
> I don't know.  I'm getting more evidence that most (if not all) of the
> failures are due to compile-time parsing screwups, so the AST merge is
> a prime suspect.
> 
> Is it possible that generated parse tables (whatever) are out-of-date
> on a Windows box?  There are no makefiles here, and the Windows build
> has always relied on Unix-heads to check in correct generated parser
> files.
> 
> 
>>>The code up to the first failure is short:
>>>
>>>bom = '\xef\xbb\xbf'
>>>compile(bom + 'print 1\n', '', 'exec')
>>>
>>>Curiously, that sequence doesn't blow up under the released Windows
>>>Python 2.4.2, so somebody broke something here since then ...
> 
> 
>>There were a bunch of changes to Parser/tokenizer.c to handle error
>>conditions.  Those go back to Oct 1.  I don't *think* those would
>>cause these, but I'm not sure.
>>
>>Sorry, I don't know any more.  I guess you might have to binary search
>>by date to try and find the problem.
> 
> 
> That's just silly ;-)  What I need is someone who understands what
> this code is _supposed_ to do, so we can fix it; finding the checkin
> that caused it isn't nearly as interesting.  Windows has an excellent
> debug-build debugger and I can easily step through the code.  But I
> have no idea why compiling a string starting with  '\xef\xbb\xbf'
> should _not_ be a syntax error -- it looks like a syntax error to me.
> 
> And when I step thru the code, it looks like a syntax error to the
> parser too.  It peels off the first character (\xef), and says "syntax
> error" at that point:
> 
> Py_CompileStringFlags ->
> PyParser_ASTFromString ->
> PyParser_ParseStringFlagsFilename ->
> parsetok ->
> PyTokenizer_Get
> 
> That sets `a` to point at the start of the string, `b` to point at the
> second character, and returns type==51.  Then `len` is set to 1, 
> `str` is malloc'ed to hold 2 bytes, and `str` is filled in with
> "\xef\x00" (the first byte of the input, as a NUL-terminated C
> string).
> 
> PyParser_AddToken then calls classify(), which falls off the end of
> its last loop and returns -1:  syntax error.
> 
> So how it gets there is really quite straightfoward.  The problem for
> me is that I have no idea why it _should_ do something other than
> that, let alone what that may be.

PEP

Re: [Python-Dev] a quit that actually quits

[Samuele Pedroni]

Michael Hudson wrote:
> [EMAIL PROTECTED] writes:
> 
> 
>>Fredrik> a quit/exit command that actually quits, instead of printing a
>>Fredrik> "you didn't say please!" message.
>>
>>I like Fredrik's idea more and more.
> 
> 
> The thing that bothers me about it is that the standard way you tell
> python to do something is "call a function" -- to me, a special case
> for exiting the interpreter seems out of proportion.
> 

also worth remarking is that is quite a FAQ at least for Jython,
how to convince python to accept bare words (plus args) as function
calls. So this magic is confusing and in the wrong direction
from that point of view, given that we don't plan to support that
at all.



> In other news, clever hacks with tb_next and so on also seem
> excessive.  Why not have the equivalent of "if input.rstrip() ==
> 'exit': sys.exit()" in the implementation of the interactive
> interpreter?
> 
> Cheers,
> mwh
> 

___
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 quit that actually quits

[Samuele Pedroni]

Michael Chermside wrote:
> The F-bot writes:
> 
>>in reality, some things are carefully thought out and craftily im-
>>plemented, some things are engineering tradeoffs made at a certain time,
>>and some things are just accidents -- but python-dev will happily defend
>>the current solution with the same energy, no matter what it is.
> 
> 
> +1 QOTF.
> 
> Seriously... I've seen this behavior also, but I haven't ever thought
> about it as clearly as Fredrik does here. When we go to answer questions
> we ought to pause briefly first and decide which of these categories
> applies to a given piece of behavior. I think users will be understanding
> if we're honest about what are the accidents -- every language or
> software package has some, and just because it's an accident does NOT
> mean we should "fix" it.
> 

it's indeed a matter of trade-offs. Converting NameErrors into commands
doesn't look like a good trade off in terms of expectations management
and understandable behavior. Ka-Ping Yee ExitHatch still seem a 
reasonable improvement. Fernando Perez considerations about Python
vs. "commands" and prefixing and extra-linguistic extensions seem
also on spot. It's not a matter of defending the status quo, more about
what kind of price is reasonable for DWIM.
___
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 quit that actually quits

[Samuele Pedroni]

Nick Coghlan wrote:
> Samuele Pedroni wrote:
> 
>>Michael Chermside wrote:
>>
>>>The F-bot writes:
>>>
>>>
>>>>in reality, some things are carefully thought out and craftily im-
>>>>plemented, some things are engineering tradeoffs made at a certain time,
>>>>and some things are just accidents -- but python-dev will happily defend
>>>>the current solution with the same energy, no matter what it is.
>>>
>>>+1 QOTF.
>>>
>>>Seriously... I've seen this behavior also, but I haven't ever thought
>>>about it as clearly as Fredrik does here. When we go to answer questions
>>>we ought to pause briefly first and decide which of these categories
>>>applies to a given piece of behavior. I think users will be understanding
>>>if we're honest about what are the accidents -- every language or
>>>software package has some, and just because it's an accident does NOT
>>>mean we should "fix" it.
> 
> 
> Most of the times I've asked questions along these lines I've gotten 
> well-considered answers (usually because something I thought was a deliberate 
> design decision on Guido's part turned out to simply be an accident of the 
> way 
> it happened to be implemented in CPython).
> 
> 
>>it's indeed a matter of trade-offs. Converting NameErrors into commands
>>doesn't look like a good trade off in terms of expectations management
>>and understandable behavior. Ka-Ping Yee ExitHatch still seem a 
>>reasonable improvement. Fernando Perez considerations about Python
>>vs. "commands" and prefixing and extra-linguistic extensions seem
>>also on spot. It's not a matter of defending the status quo, more about
>>what kind of price is reasonable for DWIM.
> 
> 
> I think Fredrik has made an excellent case for promoting the quit & exit 
> interpreter-only builtins to be proper callables.
> 

notice that I wrote that Ka-Ping Yee ExitHatch is an improvement!

> Hell, we even have that capability for the callable that displays the 
> *license* text. . . surely quitting the interpreter is far more important 
> than 
> being able to display the license text, but the support for the latter is 
> significantly better:
> 
> 
> Python 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> Py> exit
> 'Use Ctrl-Z plus Return to exit.'
> Py> quit
> 'Use Ctrl-Z plus Return to exit.'
> Py> license
> Type license() to see the full license text
> Py> type(license)
> 
> 
> Counting blank lines, 60 lines of site.py are devoted to getting copyright, 
> credit and license to work right, 16 to getting help to work, and only 12 to 
> setting quit and exit to the 'right' strings - and due to modules like 
> readline for Windows and differences in the way interpreters buffer the line 
> input, the exit string for Windows is not always correct.
> 
> Cheers,
> Nick.
> 

___
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] some interesting readings

[Samuele Pedroni]

because I was reminded of them recently, because they may be useful 
landmarks in the prospective of future discussions, because expanding
one's understanding of the problem/solution space of language design
is quite a good thing if one is interested in such things...

1)
Gilad Bracha.  Pluggable Type Systems . OOPSLA04 Workshop on Revival of 
Dynamic  Languages  ( 
http://pico.vub.ac.be/%7Ewdmeuter/RDL04/papers/Bracha.pdf )

As a talk:
Pluggable Types, originally given at Aarhus University in March 2003, 
and repeated since at Berne and elsewhere.
( http://bracha.org/pluggable-types.pdf )

2)
http://homepages.cwi.nl/~ralf/OOHaskell/
state of the art experiment on trying to reconcile object orientation, 
type inference and as much as possible expressiveness

PS: I think 1 is much more relevant than 2 for Python as we know it.

happy reading.





___
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] Draft proposal: Implicit self in Python 3.0

[Samuele Pedroni]

Ralf W. Grosse-Kunstleve wrote:
> --- Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 
>>>Please try the code below to see the performance impact.
>>
>>oh, please.  do you seriously think that if you don't have to type "self"
>>yourself, Python will suddenly be able to turn all instance variables into
>>local function variables without any performance overhead ?
> 
> 
> Yes, exactly, since you can make the local namespace vs. instance attribute
> distinction in C.
> 
> Cheers,
> Ralf
> 
> 

that indeed proves why this discussion for whatever value it has, 
belongs to comp.lang.python. This is not a place to clarify people
how Python currently works, or to have discussions made of guesses and 
half-formed speculations.
___
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] Draft proposal: Implicit self in Python 3.0

[Samuele Pedroni]

Ian Bicking wrote:
> Tim Peters wrote:
> 
>>[Thomas Wouters]
>>
>>
>>>My point isn't that it isn't archived somewhere (mailinglists, wiki, FAQ,
>>>the minds of many, many people, not just Python developers) but that it
>>>isn't easily findable and it isn't easily accessible in a single location. I
>>>thought PEP's where supposed to be that, and if I have a particular idea for
>>>new syntax or new semantics, PEPs would be the place I'd look, not the FAQ
>>>or a Wiki.
>>
>>
>>Luckily, in his benevolent infinite wisdom, I expect Guido reserved
>>PEP number 13 for exactly this purpose:  for a meta-PEP to record the
>>unlucky PEP ideas that are so unlikely to get accepted that it's not
>>worth anyone's time to write an actual PEP for them.  I like the
>>title:
>>
>>Don't Bother:  PEPs Rejected Before Being Written
>>
>>No, I'm not kidding.  At least I don't think I am.
> 
> 
> +1.  I think it's rather patronizing to send things back to python-list 
> when you know people are wasting their time discussing them because they 
> will never be accepted.

Well, the problem is that most of these proposers think that their 
proposal deserve attention, is valuable no matter what, but python-dev
is not the place to defuse/clarify that in a gentle way for the 
proposer. Of course some people do exactly that here out of kindness 
etc., I personally don't think it's a good approach.
python-list is a better place to get clarifications about the way Python
is, will stay.

Half-baked, not well thought out ideas, as huge threads in the past
going nowhere have proven, are not healthy to python-dev s/n ratio.

Even with such a valuable PEP in place, I expect some people to need 
clarification discussions and python-list will still be the right place 
to have them.


>  People on python-list have useful things to do 
> too, they don't just read to waste their time.
> 
> I would prefer PEP form over a wiki page, as I'd rather this be truly 
> authoritative, and only Guido can really completely reject an idea. 
> Justifying the rejections can be done by anyone though; maybe each idea 
> could link to a wiki page on the topic.
> 
> I think it's also important to be clear on what's being rejected.  Often 
> these rejected ideas address a real issue, and if you think about the 
> issue from another angle you might be able to solve that without falling 
> into the trap that the oft-rejected proposal fell into.  But it's easy 
> to confuse that the issue or use case is being explicitly ignored, 
> rather than the particulars.  For instance, Thomas said "changing all 
> statements into expressions (e.g. logix): python isn't (going to be) a 
> functional language" -- and that's what shouldn't be in the PEP.  All 
> statements aren't going to be expressions; the editorialization that 
> Python isn't going to be a functional language is both rather 
> inaccurate, misses the real reason for statements, and needlessly 
> alienates people who like functional programming (and they have been 
> *needlessly* alienated by discussions about lambda and filter).
> 
> So... maybe Guido or python-dev should write/vet the justifications too. 
>   When you are putting up walls and specifically discouraging community 
> participation on certain issues, it should be done in a sensitive way.
> 
> 

___
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] Draft proposal: Implicit self in Python 3.0

[Samuele Pedroni]

Ian Bicking wrote:
> I just don't want people to feel discouraged when they try to contribute 
> to the Python community and a PEP 13 could help direct people towards 
> areas where their contributions are more likely to be useful. 

but people have a lot of options, probably more effective, ranging
from writing great applications in Python, great libraries ... plus 
implementation work before they are left with the hard option that is 
language design to contribute to the community.

> Also I 
> think it is unfair to use python-list to clarify things that python-dev 
> is not willing to clarify itself.
> 

notice that the intersection is not empty yet.

Also PEP 1 contains

"""
PEP authors are responsible for collecting community feedback on a PEP 
before submitting it for review. A PEP that has not been discussed on 
python-list@python.org and/or python-dev@python.org will not be 
accepted. However, wherever possible, long open-ended discussions on 
public mailing lists should be avoided. Strategies to keep the 
discussions efficient include: setting up a separate SIG mailing list 
for the topic, having the PEP author accept private comments in the 
early design phases, setting up a wiki page, etc. PEP authors should use 
their discretion here.
"""

in the past it often happened that water testing, honing
for a PEP happend on python-list before any long discussion went on
on python-dev. Basically I think that throwing half-cooked ideas at 
python-dev, especially for people with no track-record of language 
design contributions to Python, is just a recipe for frustration.

___
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