+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 manage
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
l
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
-
On Tue, Apr 21, 2015 at 9:09 AM, Chris Angelico 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 =
+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 implementatio
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 equivale
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 b
On Mon, Jun 9, 2014 at 9:03 PM, Steven D'Aprano 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 M
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
://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
wrote:
> 2017-05-31 17:45 GMT+02:00 Jim Baker :
> > Given that this proposed new feature is for 2.7 to support event loop
> usage
> > and not a security f
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 Wed, Jun 7, 2017 at 2:31 AM, Cory Benfield wrote:
>
> On 6 Jun 2017, at 18:49, Jim Baker 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,
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. J
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 no
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’
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 \ o
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. Sm
ne 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/
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
&
> 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
___
P
ve 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
Oops, didn't attach the entire thread, so see below:
On Wed, Apr 8, 2009 at 9:50 AM, Jim Baker 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 requi
ing 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
23 matches
Mail list logo