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
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
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’
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
+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
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
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,
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
://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
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
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
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
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 =
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
-
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
+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
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
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
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
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
> 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
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
&
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/
23 matches
Mail list logo
