This list is for the development *of* the Jython implementation, not
development of applications *with* Jython.
The jython-users list is a better target and reaches more readers, one
of whom may recognise your use.
Jeff Allen
On 12/02/2018 18:53, pr144 via Jython-dev wrote:
> I see a log of examples of sending attachments... via Jython code.
>
> I need to login to an SMTP server and detach a file, can this be done?
>
> Thanks....
>
> PR
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

Also sent this mail to Jython Users list... but I'm told this group gets more looks.
Has anyone succeeded in getting Jython to work with Gradle?
I'm aware of two Jython-Gradle plugins:
com.github.rzabini.gradle-jyton
com.github.hierynomus.jython
... but both of these seem to have been put together for purely Python-oriented purposes.
In fact I opened an "issue" with the rzabini Github project and the author said he didn't know how to get this done. The other one hasn't replied at the time of writing but I don't hold out that much hope.
It is slightly frustrating as one should be able to do this moderately easily, I would have thought, given that the .jars can be on either the PYTHONPATH or the CLASSPATH. The problem being that Gradle handles dependency management automatically, squirrelling away dependency jars in quite complicated paths under GRADLE_HOME.
Unfortunately I don't know enough about the internal workings of Gradle to have much of a clue about this.
HINT (!):
Jim Baker himself said, in Jan 2016, that Gradle use would be a "top priority" for 2.7.2.: Issue 2182: Build Jython with Gradle - Jython tracker
|
| |
Issue 2182: Build Jython with Gradle - Jython tracker
| |
|

The DevGuide is now at http://jython-devguide.readthedocs.io, warts and all.
This involved a bit of branch renaming at
https://github.com/jython/devguide (to make "master" mean the Jython
version) so beware if you have this cloned.
I think making it appear as http://www.jython.org/devguide is a further
step when the website is differently hosted.
Jeff Allen
On 23/10/2017 19:19, Jim Baker wrote:
> Some top posting first:
>
> We should just use read the docs; and point our CNAME for jython.org
> <http://jython.org&gt; (and related domains) to it
> (http://docs.readthedocs.io/en/latest/alternate_domains.html).
> Currently there are too many bottlenecks to getting stuff done in
> Jython, and that's super frustrating. Automation can resolve some of
> these bottlenecks. Also I don't want to be one of the bottlenecks
> myself!!! Did I say I wanted to work on docs earlier this summer? I
> did work a bit on it privately, but then it got buried under my
> general pile of stuff. This should not be stopping anyone else working
> on this issue however.
>
> Anyway...
>
> I have an existing RTD project,
> https://readthedocs.org/projects/jython/ Rather than having it point
> to the Jython book, it might make more sense to have be the overall
> project or at least to https://github.com/jython/docs (not there
> yet!). See subproject support:
> http://docs.readthedocs.io/en/latest/subprojects.html
>
> Jeff, and others here, I can add you to the jython project on RTD as
> admins. Just need your username.
>
> There may be better approaches, but nothing is as simple as RTD given
> the source is reStructuredText. Also IIRC, RTD does allow some degree
> of customization of the look, although I personally would be so much
> happier with fresh and current content, vs any customization!
>
>
> On Mon, Oct 23, 2017 at 1:40 AM, Jeff Allen <ja.py@...
> <mailto:ja.py@...>> wrote:
>
> I've finished my preliminary restructuring of the developers'
> guide at https://github.com/jython/devguide
> <https://github.com/jython/devguide&gt;.
>
> +1
>
> You'll recall that one of the prompts for this was lessening
> support for hg.python.org <http://hg.python.org&gt;. We want to
> follow CPython and get the Jython source over to GitHub. For that
> we need a changed core development and contribution process, like
> CPython's, where everyone can read it. So far, I have:
>
> 1. Stolen CPython's text and structure.
> 2. Assessed which pages work for us unchanged or with only minor
> change.
> 3. Made parallel pages (name_jy.rst) where the content differs
> widely.
> 4. Integrated Frank's Jython-specific text from the current
> devguide into those and some unique pages.
> 5. Added a bit of content myself.
> 6. Contributed a few technical improvements upstream to the
> CPython devguide.
> 7. Merged changes from the upstream CPython devguide (not just
> mine) into the Jython devguide.
>
> The merge was not totally painless, but only 3 files gave me
> conflicts. It took a couple of hours with kdiff3, and working
> carefully from the Git Book. It's feasible, but there may be a
> better way. Two of these files had a lot of differences. Somehow
> kdiff3 seemed to guess correctly nearly everywhere.
>
> Yay, tools! Given the scope of just the devguide, it's good to hear
> that it worked so well.
>
> Could we think about how we publish this so it becomes a
> functional replacement for http://www.jython.org/devguide ? It is
> not ready yet, but if we all think it will be, then the question
> becomes how. I could set up publishing to readthedocs (on my own
> account), but do we have a Jython/PSF one? Or is it better to take
> the html to jython.org <http://jython.org&gt; as we have previously?
>
> It was nice to see my PRs to the CPython guide, once accepted, go
> live on docs.python.org <http://docs.python.org&gt; within hours. I
> assume this happens automatically. That's to aim for, I think,
> creating one decision point (the PR acceptance) and giving the
> rest of the job to machines.
>
>
> +100
>

Hi Jeff,
That's not the problem that affects windows, i think on windows it requires
the `winreg` module, which is not implemented.
The `_frozen_importlib` is not normal blobs, it's the equivalent of cpython
frozen module, which is the compiled code of the `importlib/_bootstrap` and
`importlib/_bootstrap_external`, it's need to bootstrap the import
machinery. The problem here is that it should use
ClassLoader.getResourceAsStream to read the class file instead of using a
hardcoded file reader.
Cheers,
Isaiah
On Thu, 4 Jan 2018 at 19:02 Jeff Allen <ja.py@...> wrote:
> Hi Isaiah.
>
> Since that module stops Jython 3 running on Windows, it would be good to
> have a little account of how to build it from source. There's a section in
> the developer guide intended for that. (
> http://jython-devguide.readthedocs.io/en/jython/setup_jy.html#manually-regenerated-files
> )
>
> Generally we'd like to reduce/eliminate checked in blobs, but that's a
> longer work.
> Jeff
>
> Jeff Allen
>
> On 04/01/2018 10:00, Isaiah Peng wrote:
>
> The file is actually there, but since it uses relative path, you have to
> execute the command with "dist/bin/jython". Hope it helps.
>
> On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <issaria@...> wrote:
>
>> Hi Patrick,
>>
>> That's my fault, I forgot to commit the "frozen" module, also the path is
>> hardcoded, but will handle that later.
>> Will let you know when I have a fix.
>>
>> Regards,
>> Isaiah
>>
>>
>

Hi Isaiah.
Since that module stops Jython 3 running on Windows, it would be good to
have a little account of how to build it from source. There's a section
in the developer guide intended for that.
(http://jython-devguide.readthedocs.io/en/jython/setup_jy.html#manually-regenerated-files)
Generally we'd like to reduce/eliminate checked in blobs, but that's a
longer work.
Jeff
Jeff Allen
On 04/01/2018 10:00, Isaiah Peng wrote:
> The file is actually there, but since it uses relative path, you have
> to execute the command with "dist/bin/jython". Hope it helps.
>
> On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <issaria@...
> <mailto:issaria@...>> wrote:
>
> Hi Patrick,
>
> That's my fault, I forgot to commit the "frozen" module, also the
> path is hardcoded, but will handle that later.
> Will let you know when I have a fix.
>
> Regards,
> Isaiah
>

The file is actually there, but since it uses relative path, you have to
execute the command with "dist/bin/jython". Hope it helps.
On Thu, 4 Jan 2018 at 10:48 Isaiah Peng <issaria@...> wrote:
> Hi Patrick,
>
> That's my fault, I forgot to commit the "frozen" module, also the path is
> hardcoded, but will handle that later.
> Will let you know when I have a fix.
>
> Regards,
> Isaiah
>
> On Thu, 4 Jan 2018 at 03:47 Patrick Palczewski <psykiatris@...>
> wrote:
>
>> I was able to find the Jython3 package on GitHub, so I coned the
>> reposaitory.
>>
>> I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other
>> instructions in the README file). It reported a successful build. I am
>> using the openJDK-9 (well, my system says: javac 9-internal). Could that be
>> the reson? I've had no problems until now and works when building 2.7.2.
>>
>> When I execute ./jython, I get the following:
>>
>> java.io.FileNotFoundException:
>> src/resources/frozen_importlib/_frozen_importlib.class (No such file or
>> directory)
>> at java.io.FileInputStream.open0(Native Method)
>> at java.io.FileInputStream.open(FileInputStream.java:195)
>> at java.io.FileInputStream.<init>(FileInputStream.java:138)
>> at org.python.core.PySystemState.doInitialize(PySystemState.java:1152)
>> at org.python.core.PySystemState.initialize(PySystemState.java:1007)
>> at org.python.core.PySystemState.initialize(PySystemState.java:962)
>> at org.python.core.PySystemState.initialize(PySystemState.java:957)
>> at org.python.util.jython.run(jython.java:254)
>> at org.python.util.jython.main(jython.java:141)
>> Exception in thread "main" java.lang.NullPointerException
>> at org.python.core.imp.import_next(imp.java:735)
>> at org.python.core.imp.import_first(imp.java:770)
>> at org.python.core.imp.load(imp.java:616)
>> at org.python.core.Py.importSiteIfSelected(Py.java:1922)
>> at
>> org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114)
>> at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92)
>> at
>> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39)
>> at
>> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28)
>> at
>> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68)
>> at
>> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54)
>> at
>> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34)
>> at org.python.util.jython.run(jython.java:275)
>> at org.python.util.jython.
>>
>> Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8
>> also.
>>
>> My system is Ubuntu 16.04.
>>
>>
>> Thanks,
>> - *Patrick Palczewski*
>> *VRS# 818.208.2344 <(818)%20208-2344>*
>> *Sent from Thunderbird Mail for Linux*
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Jython-dev mailing list
>> Jython-dev@...
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>

Hi Patrick,
That's my fault, I forgot to commit the "frozen" module, also the path is
hardcoded, but will handle that later.
Will let you know when I have a fix.
Regards,
Isaiah
On Thu, 4 Jan 2018 at 03:47 Patrick Palczewski <psykiatris@...> wrote:
> I was able to find the Jython3 package on GitHub, so I coned the
> reposaitory.
>
> I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other
> instructions in the README file). It reported a successful build. I am
> using the openJDK-9 (well, my system says: javac 9-internal). Could that be
> the reson? I've had no problems until now and works when building 2.7.2.
>
> When I execute ./jython, I get the following:
>
> java.io.FileNotFoundException:
> src/resources/frozen_importlib/_frozen_importlib.class (No such file or
> directory)
> at java.io.FileInputStream.open0(Native Method)
> at java.io.FileInputStream.open(FileInputStream.java:195)
> at java.io.FileInputStream.<init>(FileInputStream.java:138)
> at org.python.core.PySystemState.doInitialize(PySystemState.java:1152)
> at org.python.core.PySystemState.initialize(PySystemState.java:1007)
> at org.python.core.PySystemState.initialize(PySystemState.java:962)
> at org.python.core.PySystemState.initialize(PySystemState.java:957)
> at org.python.util.jython.run(jython.java:254)
> at org.python.util.jython.main(jython.java:141)
> Exception in thread "main" java.lang.NullPointerException
> at org.python.core.imp.import_next(imp.java:735)
> at org.python.core.imp.import_first(imp.java:770)
> at org.python.core.imp.load(imp.java:616)
> at org.python.core.Py.importSiteIfSelected(Py.java:1922)
> at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114)
> at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92)
> at
> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39)
> at
> org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28)
> at
> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68)
> at
> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54)
> at
> org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34)
> at org.python.util.jython.run(jython.java:275)
> at org.python.util.jython.
>
> Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8
> also.
>
> My system is Ubuntu 16.04.
>
>
> Thanks,
> - *Patrick Palczewski*
> *VRS# 818.208.2344 <(818)%20208-2344>*
> *Sent from Thunderbird Mail for Linux*
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>

I was able to find the Jython3 package on GitHub, so I coned the
reposaitory.
I built it with Ant like I did for Jython 2.7.2a1+ (seeing no other
instructions in the README file). It reported a successful build. I am
using the openJDK-9 (well, my system says: javac 9-internal). Could that
be the reson? I've had no problems until now and works when building 2.7.2.
When I execute ./jython, I get the following:
java.io.FileNotFoundException:
src/resources/frozen_importlib/_frozen_importlib.class (No such file or
directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at org.python.core.PySystemState.doInitialize(PySystemState.java:1152)
at org.python.core.PySystemState.initialize(PySystemState.java:1007)
at org.python.core.PySystemState.initialize(PySystemState.java:962)
at org.python.core.PySystemState.initialize(PySystemState.java:957)
at org.python.util.jython.run(jython.java:254)
at org.python.util.jython.main(jython.java:141)
Exception in thread "main" java.lang.NullPointerException
at org.python.core.imp.import_next(imp.java:735)
at org.python.core.imp.import_first(imp.java:770)
at org.python.core.imp.load(imp.java:616)
at org.python.core.Py.importSiteIfSelected(Py.java:1922)
at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:114)
at org.python.util.PythonInterpreter.<init>(PythonInterpreter.java:92)
at
org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:39)
at
org.python.util.InteractiveInterpreter.<init>(InteractiveInterpreter.java:28)
at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:68)
at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:54)
at org.python.util.InteractiveConsole.<init>(InteractiveConsole.java:34)
at org.python.util.jython.run(jython.java:275)
at org.python.util.jython.
Should I build with a different Java? I have JDK1.8.0_151 and OpenJDK-8
also.
My system is Ubuntu 16.04.
Thanks,
- *Patrick Palczewski*
_VRS# 818.208.2344_
/Sent from Thunderbird Mail for Linux/

The point of having a copy of the list would be to prevent this:
>>> s = PyShadowString("hello", "bonjour")
>>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
>>> t = s[:3]
>>> t == "bon"
True
>>> s. gettargets().pop()
('org\\.python\\.util\\.InteractiveConsole',)
>>> t == "bon"
False
It is not a problem if the slice is only transient, as in if
sys.platform[:4] == 'java' , which I agree is the only sort of slicing
attested in the stdlib. If we imagine a slice getting a life of its own,
the behaviour above would be very confusing, but I'm happy to risk that
for now.
I think I have a decent implementation now of these several changes.
Jeff
Jeff Allen
On 27/11/2017 21:31, Stefan Richthofer wrote:
> > I wonder why we write if sys.platform[:4] == 'java' anyway. It's
> more work than startswith and you have to count to 4 yourself.
> It's a matter of fact that external libraries sometimes use slicing
> for platform check. So far the implementation served all use cases I
> found.
> > suggest we expect PyShadowString(a, b)[m,n] to be
> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
> Good spot. Luckily this is mostly used for "win" which is shorter than
> "java", but of course your version is safer and more correct.
> Please let's apply that.
> > Also, if the targets list is mutable, I think each slice must have
> its own.
> I'm not sure if that is necessary. At least for all use cases I know
> it is fine if the slice inherits or shares target list from/with the
> original PyShadowString. Do I overlook something?
> *Gesendet:* Montag, 27. November 2017 um 21:33 Uhr
> *Von:* "Jeff Allen" <ja.py@...>
> *An:* "Stefan Richthofer" <Stefan.Richthofer@...>
> *Cc:* "Jython Developers" <jython-dev@...>
> *Betreff:* Re: PyShadowString test, ideas, questions
>
> Thanks Stefan:
>
> I'm happy with your answers. I have tried isBaseType = true and can
> run the str tests now (passes of course). I've added a *Derived.java file.
>
> 7. Slicing is interesting. Nice touch.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s[:3]
> 'hel ( ==bon for targets )'
>
> I appreciate the main use case is sys.platform[:n] , but these were
> surprising (because the slice is only interpreted relative to the main
> string):
>
> >>> s[:7]
> 'hello ( ==bonjo for targets )'
>
> >>> s[-3:]
> 'llo ( ==njo for targets )'
>
> I suggest we expect PyShadowString(a, b)[m,n] to be
> PyShadowString(a[m,n], b[m,n]), and I can see advantages to that.
> Also, if the targets list is mutable, I think each slice must have its
> own.
>
> I wonder why we write if sys.platform[:4] == 'java' anyway. It's more
> work than startswith and you have to count to 4 yourself.
>
> Jeff
>
> Jeff Allen
> On 26/11/2017 10:16, Stefan Richthofer wrote:
>
> Trying to give answers as far as I have them...
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> I think that's okay. target list is not private to alow
> monkeypatching etc in usual Python fashion.
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> No opinion. This behavior looks okay to me. Whoever uses
> PyShadowString must be aware of entering evil zone anyway.
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here
> there is "added value" in __eq__ (also in PyString.__eq__).
> shadowstr___eq__ will be exposed as __eq__, and shouldn't
> PyShadowString.__eq__ do the same thing? What we need is
> complicated by the wrapper PyObject._eq.
>
> I think you're right. The check for isTarget should be moved to
> shadowstr___eq__ I suppose. Sorry I overlooked this when I wrote it.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there
> are no targets that match. The problem is in isTarget() and so I
> think I will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> Thats' s a good improvement. Also, isTarget should fail-fast if
> target list is empty (I thought I had done it that way).On the
> other hand, performance is hardly a priority here, because
> platform checks are usually rather seldom, mostly on startup only.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also
> a str, but they fail because it cannot be sub-classed. Is there a
> reason to prevent sub-classing?
>
> This is because of isBaseType = false? We can remove that. I just
> felt that shadow string contains enough magic and should not be
> further extended, but there is no concrete reason. We can allow
> subclassing.
>
> 6. And relatedly, when I was working on PyType I noticed that it
> is possible to expose a Java sub-class as the same Python type as
> its parent. This would mean that type(PyShadowString("a", "b"))
> would be str even though the behaviour is different. This sounds
> worth trying.
>
> Hmm, I don't like that. ShadowString is not a string and its type
> should be labled accordingly.
>
> *Gesendet:* Sonntag, 26. November 2017 um 09:06 Uhr
> *Von:* "Jeff Allen" <ja.py@...>
> *An:* "Jython Developers" <jython-dev@...>,
> "Stefan Richthofer" <Stefan.Richthofer@...>
> *Betreff:* PyShadowString test, ideas, questions
>
> I've added a test for PyShadowString, our string that can have two
> values at once. Trying to design a test raises some questions.
>
> >>> s = PyShadowString("hello", "bonjour")
> >>> s == 'bonjour'
> False
> >>> s.addtarget(r"org\.python\.util\.InteractiveConsole")
> >>> s == 'bonjour'
> True
>
> So far so good.
>
> 1. Should I be able to do this?
>
> >>> s.gettargets().pop()
> ('org\\.python\\.util\\.InteractiveConsole',)
> >>> s == 'bonjour'
> False
>
> 2. This seems like a useful "unconditional", but I wonder if it is
> harmful:
>
> >>> s.addtarget(None)
> >>> s == 'bonjour'
> True
>
> 3. Confusing subject, but I'm not sure the exposure of __eq__ is
> "canonical". I think the convention is __eq__ just wraps
> shadowstr___eq__, as done for startswith and __repr__, but here
> there is "added value" in __eq__ (also in PyString.__eq__).
> shadowstr___eq__ will be exposed as __eq__, and shouldn't
> PyShadowString.__eq__ do the same thing? What we need is
> complicated by the wrapper PyObject._eq.
>
> 4. Single-stepping through __eq__ I notice that a call like s ==
> 'bonjour' (i.e. a call to __eq__) is quite costly, even when there
> are no targets that match. The problem is in isTarget() and so I
> think I will try changing the logic to:
>
> return other==string || (other==shadow && isTarget())
>
> but also, we can make isTarget() cheaper.
>
> 5. I tried the tests of str on PyShadowString, to prove it is also
> a str, but they fail because it cannot be sub-classed. Is there a
> reason to prevent sub-classing?
>
> 6. And relatedly, when I was working on PyType I noticed that it
> is possible to expose a Java sub-class as the same Python type as
> its parent. This would mean that type(PyShadowString("a", "b"))
> would be str even though the behaviour is different. This sounds
> worth trying.
>
> Jeff
>
> --
> Jeff Allen
>