[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim Baker]

I did make the following arguments about less indentation in
https://github.com/gvanrossum/patma/issues/59

To recap:

   1. Similarity to if/elif/else and try/except/finally statements in how
   code lines up
   2. Less apparent complexity, since indentation is a visual signal for
   such
   3. Smaller, more meaningful diffs when refactoring if/elif/else chains

Just to be clear, I wanted to capture these as possible objections, I'm not
greatly in favor of one indentation scheme or the other - there are good
arguments for the indentation scheme of the current PEP (which it makes).

- Jim

On Fri, Jul 10, 2020 at 5:11 PM Paul Sokolovsky  wrote:

> Hello,
>
> On Sat, 11 Jul 2020 00:35:39 +0200
> Federico Salerno  wrote:
>
> []
>
> > A few emails ago I proposed something like this (and I'm probably
> > only the last one to do so amongst many), but if anyone made an
> > argument against it I must have missed it:
>
> The PEP itself in "rejected" ideas makes an argument against it:
> indented stuff after a line ending with ":" must be a *statement*. It
> would be totally nuts for that to be something else, e.g. an expression:
>
> >
> > match:
> >  a
> > case 1:
> >  ...
> > case 2:
> >  ...
> > else:
> >  ...
>
> > (The a on a separate line being arguable.)
>
> That of course leads us to the obvious idea:
>
> match a:
> case 1:
>  ...
> case 2:
>  ...
> else:
>  ...
>
>
> Of course, PEP smartly has an argument against that too, in the vein of
> "after line ending with ':', there should be an indent suite (list of
> statements)". But that's where it goes sideways. That argument is no
> better than the argument "there should be no normally looking
> identifiers with magic behavior", but look, very this PEP does exactly
> that with the identifier "_".
>
> And if the above snippet looks weird to anybody, it's only because of
> all the "case" business. There wouldn't be such a problem if it was
> instead:
>
> match a:
> | 1:
>  ...
> | 2:
>  ...
> |:
>  ...
>
> The above ML-like syntax should be perfect for almost everyone, ...
> except the PEP authors, because they have it in "rejected ideas" either.
>
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/7V7BS3ICKE5PJZD5Q2I65ALZQNXROPZU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Y652WIGSKSHOLV7YHIIXZWRK3MJOXDID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim Baker]

On Fri, Jul 10, 2020, 9:16 AM Eric Nieuwland 
wrote:

>
> On 10 Jul 2020, at 01:51, Jim Baker  wrote:
>
> ...
> Explicit namespacing (if a constant) or using a guard (if a variable)
> seems to be the right solution, as Ethan demonstrated earlier. No need for
> . or ^ or  \ or ... to disambiguate. Also it seems to me that structural
> pattern matching will build on two common usages of namespaces for
> constants:
>
> 1. Constants used from other modules are almost always used in the module
> namespace. Eg, socket.AF_UNIX or signal.SIGTERM.
> 2. New code often tends to use constants defined within an Enum namespace.
> Hopefully we will see more of this convention in usage.
>
> (Very much an aside: Interestingly with the socket module we see both used
> - it defines its constants with IntEnum and exports them traditionally. The
> namespace specifics it uses with IntEnum._convert_ to make this happen  --
> strictly speaking EnumMeta._convert, not documented, and a bit hard to
> follow -- might be possibly debatable, but it works out quite well in
> practice in providing backwards compatibility while continuing to work with
> a C source of these constants.)
>
>
>> This would also mean
>> case Point(x=\x, y=\y):
>> should be used to obtain x and y from the Point instance.
>>
>
> This approach makes deeper nesting of the structure much more cumbersome,
> I think.
>
> How to match Polygon(Point(x0,y0), Point(x1, y1), Point(x2, y2)) based on
> its structure?
> And Polygon(Point(x0,y0), p1, Point(x2, y2))?
>
>
 I'm just trying to describe what v2 of the PEP is trying to do and how it
then corresponds to a reasonable usage model. Sorry for any confusion.

So in your scenario above, Polygon and Point are used as class patterns (
https://www.python.org/dev/peps/pep-0622/#class-patterns). Consequently
they are treated accordingly and have that nice structural pattern matching
quality!

Earlier I was discussing constant patterns (
https://www.python.org/dev/peps/pep-0622/#constant-value-patterns), which
require they be namespaced in some way (a qualified name as it is described
in the PEP).

- Jim
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3KHCAINGS3TKXEZG76V7TJCRSP7UOHBW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Jim Baker]

On Thu, Jul 9, 2020 at 1:42 PM Eric Nieuwland 
wrote:

> Much of the discussion seems to focus on how to distinguish between a
> variable as a provider of a value and a variable as receiver of a matched
> value.
>
> In normal Python syntax a variable in an expression provides a value,
> please let’s keep that unchanged.
>

For patterns, these are no different than parameters for a function (either
a lambda expression or with `def`); or target assignments in unpacking
assignments. So just like I wouldn't wonder where `a` and `b` materialized
in the parameters for the function definition below

def sum2(a, b):
  return a + b

I think it will be straightforward to understand this in the context of a
`case` using a capture pattern:

match x:
  case (a, b):
 return a + b
   ...

(This commonality between cases and function definitions is further used in
Scala for example, but I don't see that approach for defining an idea of
partial functions -- not like functools.partial functions! -- as being that
useful in Python.)


> So it seems to me we should explicitly mark a variable to receive a
> matched value.
> I have seen ‘?’ suggested as a prefix to do this, ‘\’ would also do fine.
>
> This would solve the single variable issue, too:
> case foo:
> matches the value of ‘foo’, while
> case \foo:
> matches anything and stores it in ‘foo’.
>
>
Explicit namespacing (if a constant) or using a guard (if a variable) seems
to be the right solution, as Ethan demonstrated earlier. No need for . or ^
or  \ or ... to disambiguate. Also it seems to me that structural pattern
matching will build on two common usages of namespaces for constants:

1. Constants used from other modules are almost always used in the module
namespace. Eg, socket.AF_UNIX or signal.SIGTERM.
2. New code often tends to use constants defined within an Enum namespace.
Hopefully we will see more of this convention in usage.

(Very much an aside: Interestingly with the socket module we see both used
- it defines its constants with IntEnum and exports them traditionally. The
namespace specifics it uses with IntEnum._convert_ to make this happen  --
strictly speaking EnumMeta._convert, not documented, and a bit hard to
follow -- might be possibly debatable, but it works out quite well in
practice in providing backwards compatibility while continuing to work with
a C source of these constants.)


> This would also mean
> case Point(x=\x, y=\y):
> should be used to obtain x and y from the Point instance.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/3MC2ZKDVRSDYRBZSYSFDR4M6GKQXITO2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OE355Z6VWOAZZSUMILSBNHLUDFFWN37V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 611 -- why limit coroutines and classes?

[Jim Baker]

I was thinking the same thing. We should distinguish limits with respect to
the codegen process, which seem reasonable, vs runtime. Classes and
coroutines are objects, and like objects in general, the program should
have the option of filling its heap with any arbitrary objects. (Whether
wise or not, this design is not for us to arbitrarily limit. For example, I
recall that Eve Online is/was running large numbers of stackless
coroutines, possibly well in excess of 1M.)

For some comparison:
Note the JVM has it made easier to tune the use of the native heap for
class objects since Java 8, in part to relax earlier constraints around
"permgen" allocation - by default, class objects are automatically
allocated from the heap without limit (this is managed by "metaspace"). I
suppose if this was a tunable option, maybe it could be useful, but
probably not - Java's ClassLoader design is prone to leaking classes, as we
know from our work on Jython. There's nothing comparable to my knowledge
for why this would be the case for CPython class objects more than other
objects.

I also would suggest for PEP 611 that any limits are discoverable (maybe in
sys) so it can be used by other implementations like Jython. There's no
direct correspondence between LOC and generated Python or Java bytecode,
but it could possibly still be helpful for some codegen systems. Jython is
limited to 2**15 bytes per method due to label offsets, although we do have
workarounds for certain scenarios, and could always compile, then run
Python bytecode for large methods. (Currently we use CPython to do that
workaround compilation, thanks!)

Lastly, PEP 611 currently erroneously conjectures that "For example, Jython
might need to use a lower class limit of fifty or sixty thousand becuase of
JVM limits."

- Jim


On Mon, Dec 9, 2019 at 9:55 AM Guido van Rossum  wrote:

> I want to question two specific limits.
>
> (a) Limiting the number of classes, in order to potentially save space in
> object headers, sounds like a big C API change, and I think it's better to
> lift this idea out of PEP 611 and debate the and cons separately.
>
> (b) Why limit coroutines? It's just another Python object and has no
> operating resources associated with it. Perhaps your definition of
> coroutine is different, and you are thinking of OS threads?
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/CJO36YRFWCTEUUROJVXIQDMWGZBFAD5T/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RQIVRB4YHNQZ2M7GCXRRCOZHZSOSNSZL/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

[Jim Baker]

+1, as Guido correctly recalls, this language guarantee will work well with
Jython when we get to the point of implementing 3.7+.

On Sat, Nov 4, 2017 at 12:35 PM, Guido van Rossum  wrote:

> This sounds reasonable -- I think when we introduced this in 3.6 we were
> worried that other implementations (e.g. Jython) would have a problem with
> this, but AFAIK they've reported back that they can do this just fine. So
> let's just document this as a language guarantee.
>
> On Sat, Nov 4, 2017 at 10:30 AM, Stefan Krah  wrote:
>
>>
>> Hello,
>>
>> would it be possible to guarantee that dict literals are ordered in v3.7?
>>
>>
>> The issue is well-known and the workarounds are tedious, example:
>>
>>https://mail.python.org/pipermail/python-ideas/2015-Decembe
>> r/037423.html
>>
>>
>> If the feature is guaranteed now, people can rely on it around v3.9.
>>
>>
>>
>> Stefan Krah
>>
>>
>>
>> ___
>> 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/guido%
>> 40python.org
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> ___
> 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/
> jbaker%40zyasoft.com
>
>
___
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] PEP 550 and other python implementations

[Jim Baker]

re other implementations: the model presented in
https://www.python.org/dev/peps/pep-0550/#implementation seems perfectly
compatible with Jython. It's just one more thing we would add to
PyThreadState (which is what it's also called in the Jython runtime).

On Fri, Aug 25, 2017 at 7:45 PM, Jim J. Jewett  wrote:

> Should PEP 550 discuss other implementations?  E.g., the object space used
> in pypy?
>
> -jJ
>
> ___
> 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/
> jbaker%40zyasoft.com
>
>
___
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] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Jim Baker]

On Wed, Jun 7, 2017 at 2:31 AM, Cory Benfield <c...@lukasa.co.uk> wrote:

>
> On 6 Jun 2017, at 18:49, Jim Baker <jim.ba...@python.org> wrote:
>
> With Nick's suggestion of _tls_bootstrap, this has certainly become more
> complicated. I'm still thinking of the ramifications for future Jython 2.7
> support, if Python dev goes down this path. It still seems easier to me to
> avoid exposing the SSLObject/MemoryBIO model to 2.7 and instead concentrate
> on just having native TLS support. Yes, this might require more work than a
> simple backport, but everyone is resource constrained, not just the
> Requests or Jython teams.
>
>
> Oh. This hadn’t occurred to me until just now, but doesn’t PyOpenSSL (or
> anything built on CFFI) just basically not run on Jython? Or am I mistaken?
>

Sorry, I wish this were true, but PyOpenSSL is not available on Jython,
because we do not yet support CFFI for Jython. CFFI support is something we
have looked at, but we have not implemented. (There is a related and far
more ambitious project to implement support for the C Extension API,
http://jyni.org/, which Stefan Richthofer is working on with me under the
Google Summer of Code.)

Having said that, bundling PyOpenSSL for use by pip is something that we
would *not* want to do for Jython itself. We want to use  the native Java
ecosystem where possible for built-in functionality, in part because we
already have native support already to the underlying system trust
store on *all
platforms*. (Java development did all the heavy lifting for us.)

Instead our current implementation of socket/ssl/select is built on Netty,
plus some additional work for managing SSLContext in such a way that is
compatible with Python. There is an out-of-date doc I prepared describing
what was done (but broad aspects are still current): https://github.com/
jimbaker/socket-reboot


>
> My concrete suggestion is that any work on PEP 543 will benefit from
> improving the testing currently found in test_ssl as part of its
> implementation. For a variety of reasons, test functions like ssl_io_loop (
> https://github.com/python/cpython/blob/master/Lib/test/test_ssl.py#L1691)
> avoid asserting more than it can properly manage the framing of
> wrapped/unwrapped data, so for example one doesn't want to state explicitly
> when SSL_ERROR_WANT_READ would be called (too much white box at that
> point). On the other hand, the lack of unit testing of, for example,
> SSLObject.read, but instead only doing at the functional test level, means
> that there's nothing explicit testing "will raise an SSLWantReadError if it
> needs more data than the incoming BIO has available" (per the docs), or
> similar use of signaling (SSLEOFError comes to mind).
>
>
> Yeah, PEP 543 just basically assumes the stdlib’s testing of TLS doesn’t
> exist and that it’ll have to manufacture its own. Unfortunately, because it
> is attempting to abstract across many different implementations the tests
> will need to be fairly high-level: for example, there is no consistent way
> to discuss the actual size of the buffers in the buffer-based TLS
> implementation, and they are allowed to be unbounded buffers, so tests
> cannot validate that TLSWantReadError and TLSWantWriteError are ever
> actually raised: all they can do is run tests that will handle them in the
> even that they are raised and confirm the data is transferred appropriately.
>

Right, so such improved testing, regardless of level, will still be an
improvement, and we look forward to seeing it for use by Jython as well.

I should mention that we sometimes see undocumented functionality leak out.
For example,
https://docs.python.org/3/library/socket.html#socket.socket.listen doesn't
say anything about backlog=0, but the requests test suite (last time I
looked on Jython) now depends on it. We assumed it was something like
http://pubs.opengroup.org/onlinepubs/009695399/functions/listen.html, but
as described in http://bugs.python.org/issue8498, it now means that "a
server application in python that accepts exactly 1 connection", by passing
to the underlying C. More tests, more docs, please, even though of course
that's a lot of dev effort.

- Jim
___
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] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Jim Baker]

With Nick's suggestion of _tls_bootstrap, this has certainly become more
complicated. I'm still thinking of the ramifications for future Jython 2.7
support, if Python dev goes down this path. It still seems easier to me to
avoid exposing the SSLObject/MemoryBIO model to 2.7 and instead concentrate
on just having native TLS support. Yes, this might require more work than a
simple backport, but everyone is resource constrained, not just the
Requests or Jython teams.

My concrete suggestion is that any work on PEP 543 will benefit from
improving the testing currently found in test_ssl as part of its
implementation. For a variety of reasons, test functions like ssl_io_loop (
https://github.com/python/cpython/blob/master/Lib/test/test_ssl.py#L1691)
avoid asserting more than it can properly manage the framing of
wrapped/unwrapped data, so for example one doesn't want to state explicitly
when SSL_ERROR_WANT_READ would be called (too much white box at that
point). On the other hand, the lack of unit testing of, for example,
SSLObject.read, but instead only doing at the functional test level, means
that there's nothing explicit testing "will raise an SSLWantReadError if it
needs more data than the incoming BIO has available" (per the docs), or
similar use of signaling (SSLEOFError comes to mind).

The problem we have seen with Jython supporting similar functionality in
the past in socket/select/ssl is not the happy path aspects like what
ssl_io_loop tests, but underdocumented/undertested error states. So what
benefits SChannel support, for example, should benefit Jython 3's
implementation that would use Java's counterpart to SSLObject, SSLEngine.
That would be a very good outcome of these proposed PEPs.

- Jim

On Tue, Jun 6, 2017 at 4:08 AM, Nathaniel Smith  wrote:

> On Mon, Jun 5, 2017 at 8:49 PM, Nick Coghlan  wrote:
> > The reason this kind of approach is really attractive to
> > redistributors from a customer risk management perspective is that
> > like gevent's monkeypatching of synchronous networking APIs, it's
> > *opt-in at runtime*, so the risk of our accidentally inflicting it on
> > a customer that doesn't want it and doesn't need it is almost exactly
> > zero - if none of their own code includes the "import _tls_bootstrap;
> > _tls_bootstrap.monkeypatch_ssl()" invocation and none of their
> > dependencies start enabling it as an implicit side effect of some
> > other operation, they'll never even know the enhancement is there.
> > Instead, the compatibility risks get concentrated in the applications
> > relying on the bootstrapping API, since the monkeypatching process is
> > a potentially new source of bugs that don't exist in the more
> > conventional execution models.
>
> OK. To unpack that, I think it would mean:
>
> 2.7's ssl.py and _ssl.c remain exactly as they are.
>
> We create a new _tls_bootstrap.py and __tls_bootstrap.c, which start
> out as ~copies of the current ssl.py and _ssl.c code in master.
> (Unfortunately the SSLObject code can't just be separated out from
> _ssl.c into a new file, because the implementations of SSLObject and
> SSLSocket are heavily intertwined.) Then the copied files are hacked
> up to work in this monkeypatching context (so that e.g. instead of
> defining the SSLError hierarchy in C code, it gets imported from the
> main ssl.py).
>
> So: we end up with two copies of the ssl code in the py27 tree, both
> diverged from the copy that in the py3 tree, in different ways.
>
> I know that the ssl maintainers won't be *happy* about this given that
> keeping the py2 and py3 code similar is an ongoing issue and was one
> of the stated advantages of backporting SSLObject, but I don't know
> whether it's a showstopper or not; it'd be good to hear their
> perspective.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> 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/
> jbaker%40zyasoft.com
>
___
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] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Jim Baker]

So we have two distinct changes that are proposed here:

1. Support alternative implementations of TLS instead of OpenSSL. In
particular this will enable the use of system trust stores for certificates.

2. Implement ABCs and concrete classes to support MemoryBIO, etc., from 3.7.

Supporting system trust stores is a valid security fix for 2.7, and I have
no such problem with such changes as long as they are narrowed to this
specific change.

But I object to a completely new feature being added to 2.7 to support the
implementation of event loop SSL usage. This feature cannot be construed as
a security fix, and therefore does not qualify as a feature that can be
added to CPython 2.7 at this point in its lifecycle.

The discussion that implementing such new features for 2.7 will improve
their adoption for Python 3 is a red herring. We could enumerate many such
features, but https://www.python.org/dev/peps/pep-0404/#upgrade-path is
rather clear here.

- Jim

On Wed, May 31, 2017 at 10:40 AM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> 2017-05-31 17:45 GMT+02:00 Jim Baker <jim.ba...@python.org>:
> > Given that this proposed new feature is for 2.7 to support event loop
> usage
> > and not a security fix, I'm -1 on this change. In particular, it runs
> > counter to the justification policy stated in PEP 466.
>
> Hum, it seems like the PEP 546 abstract is incomplete. The final goal
> of the PEP is to make Python 3 more secure thanks to all goodness of
> the PEP 543. The PEP 546 tries to explain why Python 2.7 is blocking
> the adoption of the PEP 543 in practice.
>
> Victor
>
___
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] RFC: Backport ssl.MemoryBIO and ssl.SSLObject to Python 2.7

[Jim Baker]

Jython 2.7.1 is about to be released, with full support of upstream pip
(9.0.1), and corresponding vendored libraries, including requests.

However, this proposed new feature for CPython 2.7, and its usage, will
likely break pip on Jython 2.7.x going forward, given that future versions
of pip will depend on requests requiring MemoryBIO. Or am I wrong in this
analysis? This means we have to get back on the 2.7 development treadmill
just as we were about to focus on finally working on Jython 3 (
https://github.com/jython/jython3 previews this work).

Given that this proposed new feature is for 2.7 to support event loop usage
and not a security fix, I'm -1 on this change. In particular, it runs
counter to the justification policy stated in PEP 466.

- Jim


On Wed, May 31, 2017 at 7:25 AM, Cory Benfield  wrote:

>
> > On 31 May 2017, at 08:42, Victor Stinner 
> wrote:
> >
> > Hi,
> >
> > I wrote a PEP based on the previous thread "Backport ssl.MemoryBIO on
> > Python 2.7?". Thanks for Cory Benfield, Alex Gaynor and Nick Coghlan
> > who helped me to write it!
>
> It probably goes without saying, given that I helped with the drafting for
> the PEP, but I’m strongly in favour of this PEP. Just in case it helps to
> get that reaffirmation here. ;)
>
> Cory
>
> ___
> 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/
> jbaker%40zyasoft.com
>
___
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] New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL

[Jim Baker]

I have no vested interest in this, other than the continuing work we have
done to make Jython compatible with OpenSSL's model, warts and all.

But the fact that BoringSSL cleans up the OpenSSL API (
https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md), at the
cost of possible backwards breaking API changes looks reasonable. I suppose
there is some risk - perhaps the maintainers will decide that returning 1
should mean OK, but that's not going to happen, is it. The real issue here
is that no direct exposure of BoringSSL to other packages. I don't think
that happens with CPython. (Ironically it happens with Jython, due to how
signed jars poorly interact with shading/Java namespace remapping.)

Maintaining security means dealing with the inevitable churn. Did I mention
Jython's support of Python-compatible SSL? I think I did :p

- Jim

On Mon, Mar 14, 2016 at 6:06 PM, Gregory P. Smith  wrote:

>
> On Mon, Mar 14, 2016 at 4:56 PM Nathaniel Smith  wrote:
>
>> Should people outside google pay attention to boringssl? The first
>> thing it says on the website is:
>>
>> "Although BoringSSL is an open source project, it is not intended for
>> general use, as OpenSSL is. We don’t recommend that third parties
>> depend upon it. Doing so is likely to be frustrating because there are
>> no guarantees of API or ABI stability."
>>
>
> Heh, good point.  I guess not.  :)
>
>
>> On Mon, Mar 14, 2016 at 4:40 PM, Gregory P. Smith 
>> wrote:
>> > Don't forget BoringSSL.
>> >
>> > On Wed, Mar 9, 2016 at 9:30 AM Michael Felt  wrote:
>> >>
>> >> Can look at it. There has been a lot of discussion, iirc, between
>> OpenSSL
>> >> and LibreSSL re: version identification.
>> >> Thx for the reference.
>> >>
>> >>
>> >> On 08-Mar-16 14:55, Hasan Diwan wrote:
>> >>
>> >>
>> >> On 8 March 2016 at 00:49, Michael Felt  wrote:
>> >>>
>> >>> As a relative newcomer I may have missed a long previous discussion
>> re:
>> >>> linking with OpenSSL and/or LibreSSL.
>> >>> In an ideal world this would be rtl linking, i.e., underlying
>> >>> complexities of *SSL libraries are hidden from applications.
>> >>>
>> >>> In short, when I saw this http://bugs.python.org/issue26465 Title:
>> >>> Upgrade OpenSSL shipped with python installers, it reminded me I need
>> to
>> >>> start looking at LibreSSL again - and that, if not already done -
>> might be
>> >>> something "secure" for python as well.
>> >>
>> >>
>> >> According to the libressl website, one of the projects primary goals
>> is to
>> >> remain "backwards-compatible with OpenSSL", which is to say, to either
>> have
>> >> code work without changes or to fail gracefully when it uses the
>> deprecated
>> >> bits. It does seem it ships with OpenBSD. There is an issue open on
>> bugs to
>> >> address whatever incompatibilities remain between LibreSSL and
>> OpenSSL[1].
>> >> Perhaps you might want to take a look at that? -- H
>> >> 1. https://bugs.python.org/issue23177
>> >>>
>> >>>
>> >>> Michael
>> >>> ___
>> >>> 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/hasan.diwan%40gmail.com
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> OpenPGP: http://hasan.d8u.us/gpg.asc
>> >> Sent from my mobile device
>> >> Envoyé de mon portable
>> >>
>> >>
>> >> ___
>> >> 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/greg%40krypto.org
>> >
>> >
>> > ___
>> > 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/njs%40pobox.com
>> >
>>
>>
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>>
>
> ___
> 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/jbaker%40zyasoft.com
>
>
___
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] Benchmark results across all major Python implementations

[Jim Baker]

Brett,

Very cool, I'm glad to see that Jython's performance was competitive under
most of these benchmarks. I would also be interested in joining the
proposed mailing list.

re elementtree - I assume the benchmarking is usually done with
cElementTree. However Jython currently lacks a Java equivalent, so
importing cElementTree just uses the pure Python version. Hence the
significant performance difference of approx. 40x for etree_parse and 16x
for etree_iterparse.

- Jim

On Mon, Nov 16, 2015 at 1:18 PM, Brett Cannon  wrote:

> I gave the opening keynote at PyCon CA and then gave the same talk at
> PyData NYC on the various interpreters of Python (Jupyter notebook of my
> presentation can be found at bit.ly/pycon-ca-keynote; no video yet). I
> figured people here might find the benchmark numbers interesting so I'm
> sharing the link here.
>
> I'm still hoping someday speed.python.org becomes a thing so I never have
> to spend so much time benchmarking so may Python implementations ever again
> and this sort of thing is just part of what we do to keep the
> implementation ecosystem healthy.
>
> ___
> 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/jbaker%40zyasoft.com
>
>
___
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] Type hints -- a mediocre programmer's reaction

[Jim Baker]

On Tue, Apr 21, 2015 at 9:09 AM, Chris Angelico ros...@gmail.com wrote:

 ...

 Pretty accurate, yeah. Here's how I see it:

 def incremental_parser(input: FileLike) - List[Token]:
 tokens = []
 data = 
 while True:
 if not data:
 data = input.read(64)
 token = Token(data[0]); data = data[1:]
 while token.wants_more():
 token.give_more(data[0]); data = data[1:]
 tokens.append(token)
 if token.is_end_of_stream(): break
 input.seek(-len(data), 1)
 return tokens

 If you were to exhaustively stipulate the requirements on the
 file-like object, you'd have to say:

 * Provides a read() method which takes an integer and returns up to
 that many bytes
 * Provides a seek() method which takes two integers
 * Is capable of relative seeking by at least 63 bytes backward
 * Is open for reading
 * Etcetera


Potentially you could use io.RawIOBase as the ABC for the type you need for
FileLike, including read and seek. See the mixins in
https://docs.python.org/3/library/io.html#class-hierarchy


 That's not the type system's job. Not in Python. Maybe in Haskell,


Not in Haskell either FWIW in terms of what its type system can prove


 but
 not in Python. So how much _should_ go into the type hint? I'm happy
 with FileLike or however it's to be spelled; maybe separate readable
 files from writable ones, as those are two fairly clear variants, but
 that's about all you really need.


RawIOBase is also potential overkill... maybe you just wanted something
that duck typed for a few methods you implemented. Any and dynamic typing
is a good choice then.


 If you provide incremental_parser()
 with an input file that's non-seekable, it's going to have problems -
 and your editor may or may not even be able to detect that (some files
 are seekable but only in the forward direction, but they'll have the
 exact same seek() method).


With what has been proposed, there are no static guarantees about how many
bytes can be read, or that input is even seekable (does seekable() return
True?) or it is open for reading. Instead we can only *prove* a limited
amount in static type systems about the runtime dynamic behavior of code,
and PEP 484 is weaker than other approaches (for very good reasons IMHO).

Still useful however :)

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

[Python-Dev] Google Summer of Code

[Jim Baker]

Jython plans to participate in the Google Summer of Code for 2015. If you
are interested, I have outlined a number of projects on our ideas page that
students could work on:

   - Work on JyNI, which adds C extension API support to Jython
   - Performance optimizations, including startup time
   - Python bytecode compiler for Python source (must be written in Java!)

See https://github.com/jythontools/gsoc2015 for the ideas page. Pull
requests and comments gladly accepted to expand this list of ideas.

The ideal student must be a very strong Java developer, with an existing
track record of projects on such sites as GitHub and BitBucket. Knowledge
of C and especially of the CPython source code invariably helps. Ideally
you will also become a Jython committer as a result of your intense
participation this summer.

Note that the deadline for student proposals is very soon, Friday March 27.
I apologize we are just getting our participation for GSOC together, but we
have also been busy finalizing the Jython 2.7.0 release candidate.


-- 
- Jim

jim.baker@{colorado.edu|python.org|rackspace.com|zyasoft.com}
twitter.com/jimbaker
github.com/jimbaker
bitbucket.com/jimbaker
___
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] Multilingual programming article on the Red Hat Developer blog

[Jim Baker]

Great points here - I especially like the concluding statement you can't
treat it as a pure Unicode string - it's a Unicode string with smuggled
bytes

Given that Jython uses UTF-16 as its representation, it is possible to
frequently smuggle isolated surrogates in it. A surrogate pair must be a
low surrogate in range (D800, DC00), then a high surrogate in range(DC00,
E000). So one can likely assign an interpretation that this is in fact the
isolated surrogate, and not an actual codepoint.

Of course, if you do actually have a smuggled isolated low surrogate
FOLLOWED by a smuggled isolated high surrogate - guess what, the only
interpretation is a codepoint. Or perhaps more likely garbage. Of course it
doesn't happen so often, so maybe we are fine with the occasional bug ;)

I personally suspect that we will resolve this by also supporting UCS-4 as
a representation in Jython 3.x for such Unicode strings, albeit with the
limitation that we have simply moved the problem to when we try to call
Java methods taking java.lang.String objects.

- Jim

On Tue, Sep 16, 2014 at 9:27 AM, Chris Angelico ros...@gmail.com wrote:

 On Wed, Sep 17, 2014 at 1:00 AM, R. David Murray rdmur...@bitdance.com
 wrote:
  That isn't the case in the email package.  The smuggled bytes are not
  errors[*], they are literally smuggled bytes.

 But they're not characters, which is what Stephen and I were saying -
 and contrary to what Jim said about treating them as characters. At
 best, they represent characters but in some encoding other than the
 one you're using, and you have no idea how many bytes form a character
 or anything. So you can't, for instance, word-wrap the text, because
 you can't know how wide these unknown bytes are, whether they
 represent spaces (wrap points), or newlines, or anything like that.
 You can't treat them as characters, so while you have them in your
 string, you can't treat it as a pure Unicode string - it''s a Unicode
 string with smuggled bytes.

 ChrisA
 ___
 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/jbaker%40zyasoft.com




-- 
- Jim

jim.baker@{colorado.edu|python.org|rackspace.com|zyasoft.com}
twitter.com/jimbaker
github.com/jimbaker
bitbucket.com/jimbaker
___
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] Proposed schedule for 3.4.2

[Jim Baker]

+1 for the suggested change to 2.7.

Something I have put off in the work on SSL support in Jython 2.7 is what
to do about the possibility of adding a large security hole to support
standard Python behavior here with CERT_NONE. By default, we use the
standard trust database and corresponding manager from Java, as augmented
by any provided ca_certs. In practice, I don't think people are really
noticing that it's currently locked down in the latest beta, which added
this SSL support.

Although it's very easy to open such a hole on Jython/Java, it's much nicer
if we require the user has to do some work to do so, and on a per
connection basis.

- Jim



On Mon, Sep 8, 2014 at 10:58 AM, Guido van Rossum gu...@python.org wrote:

 On Mon, Sep 8, 2014 at 5:08 AM, Nick Coghlan ncogh...@gmail.com wrote:


 It would also be good to get Guido's official verdict on PEP 476 (the
 switch to validating HTTPS by default) in time for 3.4.2. Based on the
 previous discussion, Alex updated the PEP to suggest just fix it for
 all of 3.5, 3.4.x and 2.7.x (including the httplib SSLContext support
 backport in the latter case).


 My opinion hasn't changed since the last time I opened my mouth
 prematurely. :-) I would very much like these to go in, but for 2.7 I am
 now worried about what we should tell people who have a script that uses an
 https URL to access a service that can only be accessed via SSL/TLS to a
 self-signed or otherwise mis-configured cert. I am not insisting on an
 environment variable to disable this (too easy) but I do think it must be
 possible to make a simple change to the code, on the order of tracking down
 the urlopen() call and adding a new keyword parameter. Such a band-aid
 needn't be backward compatible (we can introduce a new keyword parameter
 for this purpose) and it needn't be totally straightforward (we can assume
 some modicum of understanding of finding and editing .py files) but it
 should definitely not require a refactor of the script (e.g. swapping out
 urlopen and replacing it with httplib or requests would be too much of a
 burden). And we should have prominent documentation (perhaps in FAQ form?)
 with an example of how to do it.


 I think that would be feasible with an rc on the 20th, but challenging
 if the rc is this coming weekend.

 Note, as I stated in the previous thread, I'm now +1 on that PEP,
 because I don't see any way to write an automated scan for a large
 code base that ensures we're not relying on the default handling at
 all. If the default behaviour is to validate HTTPS, the lack of such a
 scanner isn't a problem - any failures to cope with self-signed or
 invalid certs will be noisy, and we can either fix the certs, patch
 the code to cope with them appropriately, or (for the self-signed cert
 case) configure OpenSSL via environment variables. If dealing with
 invalid certs is truly necessary, and the code can't be updated
 either, then I'm OK with the answer being keep using an older version
 of Python, as that's going to be the least of your security concerns.


 Yeah, I am not interested in helping out the case where the user is
 incapable (for whatever reason) of tracking down and changing a couple of
 lines of code. Such users are dependent on someone else with wizard powers
 anyway (who gave them the script?).

 --
 --Guido van Rossum (python.org/~guido)

 ___
 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/jbaker%40zyasoft.com


___
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] Criticism of execfile() removal in Python3

[Jim Baker]

On Mon, Jun 9, 2014 at 9:03 PM, Steven D'Aprano st...@pearwood.info wrote:

 ...
 There's nothing stopping alternative implementations having their own
 implementation-specific standard library modules.

 steve@orac:/home/s$ jython
 Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19)
 [OpenJDK Server VM (Sun Microsystems Inc.)] on java1.6.0_27
 Type help, copyright, credits or license for more information.
  import java
 


Small nit: Jython does implement a number of implementation-specific
modules in its version of the standard library; jarray comes to mind, which
is mostly but not completely superseded by the standard array module.
However, the java package namespace is not part of the standard library,
it's part of the standard Java ecosystem and it's due to a builtin import
hook:

Jython 2.7b3+ (default:6cee6fef06f0, Jun 9 2014, 22:29:14)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_60
Type help, copyright, credits or license for more information.
 import sys
 sys.path
['', '/home/jbaker/jythondev/jython27/dist/Lib', '__classpath__',
'__pyclasspath__/', '/home/jbaker/.local/lib/jython2.7/site-packages',
'/home/jbaker/jythondev/jython27/dist/Lib/site-packages']

The entry __classpath__ means search CLASSPATH for Java packages; this
includes the Java runtime, rt.jar, from which you get package namespaces as
java.*, javax.*, sun.*, etc.

Another behavior that you get for free in Jython is being able to also
import the org.python.* namespace, which is Jython's own runtime. Some of
the implementations of standard library modules, such as threading, take
advantage of this support.

- Jim
___
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] Shorter float repr in Python 3.1?

[Jim Baker]

I rather like supporting short float representation. Given that CPython is
adopting it, I'm sure Jython will adopt this approach too as part of a
future Jython 3.x release.
- Jim

On Tue, Apr 7, 2009 at 9:41 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:

 Mark Dickinson wrote:

 [snip...]
  Discussion points
 =

 (1) Any objections to including this into py3k?  If there's
 controversy, then I guess we'll need a PEP.



 Big +1

 (2) Should other Python implementations (Jython,
 IronPython, etc.) be expected to use short float repr, or should
 it just be considered an implementation detail of CPython?
 I propose the latter, except that all implementations should
 be required to satisfy eval(repr(x)) == x for finite floats x.


 Short float repr should be an implementation detail, so long as
 eval(repr(x)) == x still holds.

 Michael Foord

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



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




-- 
Jim Baker
jba...@zyasoft.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] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!

[Jim Baker]

A question that arose on this thread, which I'm forwarding for context (and
we're quite happy about it too!):

   - What is the scope of a patch that requires a contributor agreement?
   This particular patch on #1188 simply adds obvious (in retrospect of course)
   handling on SecurityException so that it's treated in a similar fashion to
   IOException (possibly a bit more buried), so it seems like a minor patch.
   - Do Google employees, working on company time, automatically get treated
   as contributors with existing contributor agreements on file with the PSF?
   If so, are there are other companies that automatically get this treatment?
   - Should we change the workflow for roundup to make this assignment of
   license clearer (see Tobias's idea in the thread about a click-though
   agreement).

In these matters, Jython, as a project under the Python Software Foundation,
intends to follow the same policy as CPython.

- Jim

-- Forwarded message --
From: Frank Wierzbicki fwierzbi...@gmail.com
Date: Wed, Apr 8, 2009 at 9:32 AM
Subject: Re: [Jython-dev] Jython on Google AppEngine!
To: James Robinson jam...@google.com
Cc: Jython Developers jython-...@lists.sourceforge.net, Alan Kennedy 
jython-...@xhaus.com


On Wed, Apr 8, 2009 at 11:22 AM, James Robinson jam...@google.com wrote:
 I submitted 1188 and I'm a Google employee working on company time.  Let
me
 know if anything further is needed, but we have quite a few contributors
to
 the Python project working here.
Excellent, and thanks!  1188 was already slated for inclusion in our
upcoming RC, but knowing that it is in support of GAE moves it up to a
very high priority.

-Frank

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Jython-dev mailing list
jython-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev



-- 
Jim Baker
jba...@zyasoft.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] Contributor Agreements for Patches - was [Jython-dev] Jython on Google AppEngine!

[Jim Baker]

Oops, didn't attach the entire thread, so see below:

On Wed, Apr 8, 2009 at 9:50 AM, Jim Baker jba...@zyasoft.com wrote:

 A question that arose on this thread, which I'm forwarding for context (and
 we're quite happy about it too!):

- What is the scope of a patch that requires a contributor agreement?
This particular patch on #1188 simply adds obvious (in retrospect of 
 course)
handling on SecurityException so that it's treated in a similar fashion to
IOException (possibly a bit more buried), so it seems like a minor patch.
- Do Google employees, working on company time, automatically get
treated as contributors with existing contributor agreements on file with
the PSF? If so, are there are other companies that automatically get this
treatment?
- Should we change the workflow for roundup to make this assignment of
license clearer (see Tobias's idea in the thread about a click-though
agreement).

 In these matters, Jython, as a project under the Python Software
 Foundation, intends to follow the same policy as CPython.

 - Jim


Forwarded conversation
Subject: [Jython-dev] Jython on Google AppEngine!


From: *Alan Kennedy* jython-...@xhaus.com
Date: Wed, Apr 8, 2009 at 6:37 AM
To: Jython Developers jython-...@lists.sourceforge.net, jython users 
jython-us...@lists.sourceforge.net


Hi all,

As you may know, Google announced Java for AppEngine yesterday!

http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

And they're also supporting all of the various languages that run on
the JVM, including jython.

http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine

They say about jython


- Jython 2.2 works out of the box.
- Jython 2.5 requires patches which we'll supply until the changes
make it directly into Jython:
 - jython-r5996-patched-for-appengine.jar is the complete jython
binary library, patched for app engine
 - jython-r5996-appengine.patch is the patch file that contains the
source code for the changes


They provide the patches they used to make 2.5 work

http://google-appengine-java.googlegroups.com/web/jython-r5996-appengine.patch

I definitely think this is an important patch to consider for the 2.5RC!

It would be nice if Google could say Jython 2.2 works out of the box,
and jython 2.5 works out of the box.

Alan.

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Jython-dev mailing list
jython-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev

--
From: *Tobias Ivarsson* tho...@gmail.com
Date: Wed, Apr 8, 2009 at 8:18 AM
To: Alan Kennedy jython-...@xhaus.com
Cc: Jython Developers jython-...@lists.sourceforge.net


Most things in that patch look ok. I'd like to do a more thorough analysis
of the implications of each change though.

The catching of SecurityException is fine, but I want to look at the places
where they drop the exceptions that they caught in their context, and make
sure that silently ignoring the exception is a valid approach. The other
changes are few but slightly more controversial.

Are Google willing to sign a contributors agreement and license this patch
to us? otherwise someone who has not looked on it yet (i.e. not me), should
probably experiment with Jython on GAE and find out what needs to be patched
to get Jython to run there.

/Tobias

--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
___
Jython-dev mailing list
jython-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev


--
From: *Jim Baker* jba...@zyasoft.com
Date: Wed, Apr 8, 2009 at 8:33 AM
To: Alan Kennedy jython-...@xhaus.com
Cc: Jython Developers jython-...@lists.sourceforge.net, jython users 
jython-us...@lists.sourceforge.net


This is the same patch set requested in http://bugs.jython.org/issue1188:
Patch against trunk to handle SecurityExceptions. Now we know the source
of the request, and the specific application is very clear: a sandboxed
Jython, running under a fairly strict security manager.

The bug is a blocker for the release candidate, so this fix will be part of
2.5.

We would love to see more work testing the full scope of environments Jython
needs to run under, and any resulting bugs.

- Jim




-- 
Jim Baker
jba...@zyasoft.com

--
From: *James Robinson* jam...@google.com
Date: Wed, Apr 8, 2009 at 8:30 AM
To: Tobias Ivarsson tho...@gmail.com
Cc: Jython Developers jython

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

[Jim Baker]

For Jython, this proposal would not present any problems. Exceptions are in
any event of lower cost than for CPython.

Given that we have now adopted Python bytecode for various scenarios where
we cannot compile to Java bytecode, it would be nice to track any changes in
the VM such as the proposed SETUP_WITH opcode. But I'm sure we'll continue
to diff ceval.c, etc. (Consider this request perhaps fodder for the language
summit?)

- Jim

On Sun, Mar 15, 2009 at 12:37 PM, gl...@divmod.com wrote:


 On 12:56 pm, ncogh...@gmail.com wrote:

 PEP 377 is a proposal to allow context manager __enter__() methods to
 skip the body of the with statement by raising a specific (new) flow
 control exception.

 Since there is a working reference implementation now, I thought it was
 time to open it up for broader discussion.


 Why not allow a context manager to implement some other method, for the
 sake of argument let's say __start__, which was invoked with a callable
 object and could choose to evaluate or not evaluate the statement body by
 simply not calling that object (or perhaps iterable, in the case of a
 generator)?

 This PEP proposes that we have two ways to deal with the body of a 'with'
 statement: either the body is run or not.  I have always wanted to have
 another option: run the body later.

 Passing around an object representing the body of the with statement would
 allow for this use-case, as well as removing the ugly protrusion of yet
 another control-flow exception (which, as has already been noted, creates
 difficulties for some other python implementations).

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




-- 
Jim Baker
jba...@zyasoft.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] Reviving restricted mode?

[Jim Baker]

This looks very interesting. What I like about Tav's approach is that it
should also be directly applicable to Jython. Much like Jython in general,
there's a tight correspondence between typeobject.c/PyType.java and
genobject.c/PyGenerator.java. So we plan on trying out a similar, presumably
small patch too.

What will be very helpful here is identifying a set of tests that verify
these claims of restricted execution.

- Jim

On Mon, Feb 23, 2009 at 4:03 PM, tav t...@espians.com wrote:

 Hey Martin,

  The patch is a mere 6 lines of code and provides the absolute minimum
  that is needed to secure the Python interpreter!
 
  Unlike Guido, I'm not quite willing to your word for it.

 You are right. Sorry, I was a bit too enthusiastic and overstated the case.

 How about: it could possibly enable a secured Python interpreter ?

  OTOH, the patch looks harmless (with minor corrections). It could
  be considered a bug fix for the current set of restricted attributes

 Yes, and it is in that light that I would like the patch to be accepted.

 --
 love, tav

 plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
 http://tav.espians.com | http://twitter.com/tav | skype:tavespian
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/jbaker%40zyasoft.com




-- 
Jim Baker
jba...@zyasoft.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] Tracker archeology

[Jim Baker]

+1 on the cleanup: reading the bug description of
http://bugs.python.org/issue1533164, this will also help Jython. Now I know
why we see scenarios of package with setup.cfg with optimize=1:

Indeed, this is a well-known issue. Many packages put an optimize=1 in
their setup.cfg in order to solve it.

Unfortunately that breaks the setup process on Jython, since we don't
support -O. And unfortunately it's not as easy to ignore the flag either,
this can then break in other ways.

-  Jim


On Wed, Feb 11, 2009 at 2:08 AM, Tarek Ziadé ziade.ta...@gmail.com wrote:

 On Wed, Feb 11, 2009 at 12:46 AM, Stephen Thorne step...@thorne.id.au
 wrote:
  On 2009-02-10, Tarek Ziadé wrote:
  On Tue, Feb 10, 2009 at 2:23 PM, Daniel (ajax) Diniz aja...@gmail.com
 wrote:
 
  
   If anyone is interested in being added as nosy for any category of
   bugs, let me know and I'll do that as I scan the tracker.
 
  I'll take Distutils related issues,
 
  If you could look at a solution for http://bugs.python.org/issue1533164
  I would be eternally grateful.

 ok, that would be the next one I am working on in that case,

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




-- 
Jim Baker
jba...@zyasoft.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