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.
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
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
+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
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.
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 ramifica
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 <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 suppo
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
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
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)
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
+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
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
://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
/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
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
/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
___
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@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
23 matches
Mail list logo