Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 7:52:07 AM UTC+10, jak wrote: > one thing is not clear to me, do you absolutely need to use "asma"? > > http://www.z390.org/ I forgot to mention that it also requires Java. So instead of porting Python to the S/3X0 I would need to port Java. Note that Java (and Python for that matter) are available for later versions of z/OS, but as far as I am aware, they are not available for the free MVS that hobbyists use, ie MVS 3.8J, and it's definitely not available for the environment I'm actually interested in, which is PDOS/3X0. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 2:37:23 PM UTC+10, Dan Stromberg wrote: > > I want to produce EBCDIC executables that run on a > > S/3X0 (or z/Arch) machine (even if I personally do > > that via emulation). > > > I thought EBCDIC was analogous to ASCII? EBCDIC is an alternative to ASCII. E.g. the character '0' is at position x'F0' in EBCDIC compared to x'30' in ASCII. Note that in EBCDIC, the letters 'A' to 'Z' are not contiguous either, and the C90 standard has been carefully worded and designed so that you can rely on digits being contiguous, but not letters. > Is it also analogous to a.out, ELF and COFF? MVS 3.8J doesn't use any of those formats. The executable format is just called "MVS load module". And the object format is just called "object code". I'm not aware of any special names for them. PDOS/3X0 currently only runs MVS load modules, but I have plans for a PDOS-generic which will run under PDOS/3X0, and will use FAT instead of the MVS file system (basically just a VTOC, equivalent of a root directory, no subdirectories). So the VTOC would have one important flat file which PDOS-generic will access to provide a FAT facility to any applications running under PDOS-generic. Those applications will need to be specific to PDOS-generic and they may well be a.out/ELF/COFF - I haven't reached that point yet. I'm still preparing the assembler, I can't do what I want without that. :-) BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
Il 17/04/2021 10:56, Paul Edwards ha scritto: On Saturday, April 17, 2021 at 7:52:07 AM UTC+10, jak wrote: one thing is not clear to me, do you absolutely need to use "asma"? http://www.z390.org/ I forgot to mention that it also requires Java. So instead of porting Python to the S/3X0 I would need to port Java. Note that Java (and Python for that matter) are available for later versions of z/OS, but as far as I am aware, they are not available for the free MVS that hobbyists use, ie MVS 3.8J, and it's definitely not available for the environment I'm actually interested in, which is PDOS/3X0. BFN. Paul. I looked at the "asma" folder and noticed that some files were touched 6 years ago. I could deduce from this that the authors might have an older version, perhaps developed for an older version of python, probably for the 2.x versions. You could try contacting the authors to ask about this. Python 2.x porting would probably be easier. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On Saturday, April 17, 2021 at 8:12:52 PM UTC+10, jak wrote: > I looked at the "asma" folder and noticed that some files were touched 6 > years ago. I could deduce from this that the authors might have an older > version, perhaps developed for an older version of python, probably for > the 2.x versions. You could try contacting the authors to ask about > this. Python 2.x porting would probably be easier. I looked at the "README" history (where Python 3.3 is given as a requirement, down the bottom): https://github.com/s390guy/SATK/commits/master/README and I can see that on 2014-08-13 he cited 3.3 as an explicit requirement. BFN. Paul. -- https://mail.python.org/mailman/listinfo/python-list
Re: port to PDOS (especially mainframe)
On 4/16/2021 4:02 PM, Paul Edwards wrote: On Saturday, April 17, 2021 at 5:13:31 AM UTC+10, Paul Rubin wrote: Paul Edwards writes: I have succeeded in producing a Python 3.3 executable despite being built with a C library that only supports C90. Not surprising. CPython was restricted to C90 until fairly recently to be portable across major systems, including Windows with MS Visual C. At least some C99 features are used now and more are being comtemplated. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Repair Install of 64 bit python
On 4/16/2021 10:15 AM, Cameron Simpson wrote: On 16Apr2021 13:13, Dan Ciprus (dciprus) wrote: Isn't the recommended python3 way of pip-ing stuff: python3 -m pip install ... .. just curious. If there's only one Python 3 installed then "pip3 install ..." _ought_ to be equivalent. However, in the face of virtualenvs etc there may often be several pip3s. Using "python3 -m pip install ..." ensures that you are using the pip which is associated with "python3" (which you can adjust to be whichever python3 you intend). This is why the "-m pip" form is recommended: it definitely installs in the Python you'd be running. It requires that pip itself be installed for pythonx, which can be ensured with "pythonx -m ensurepip". -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
need help with a translation issue
I'm trying to take the user input and let them change the target language
or dest
code:
from deep_translator import GoogleTranslator
import googletrans
import sys
language_list = googletrans.LANGUAGES
print(language_list)
feedback = input("Would you like to translate a sentence of your own?
(yes/no)")
if feedback == 'no':
sys.exit()
while feedback == 'yes':
user_choice = input ("Enter a language (the abbreviation or correctly
spelled name of the language): ").lower()
user_sentence = input("Enter a sentence you want translated: ")
user_translation = GoogleTranslator(source='en',
target=user_choice).translate(user_sentence)
print(user_translation)
feedback = input ("Would you like to translate a sentence of your own?
(yes/no)")
if feedback == 'no':
sys.exit()
when ran, this will bring an error saying that your inputted language is
not supported
why is this?
--
https://mail.python.org/mailman/listinfo/python-list
Re: need help with a translation issue
On 18/04/2021 10.56, Quentin Bock wrote:
> I'm trying to take the user input and let them change the target language
> or dest
> code:
>
...
> language_list = googletrans.LANGUAGES
> print(language_list)
...
> user_choice = input ("Enter a language (the abbreviation or correctly
> spelled name of the language): ").lower()
...
> user_translation = GoogleTranslator(source='en',
> target=user_choice).translate(user_sentence)
Where is the "user_choice" related back to "language_list"?
Alternately, what's there to stop some nefarious/stupid user (like me!)
entering "gobbledegook" and complaining that the program fails?
--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
Re: need help with a translation issue
On 2021-04-17 23:56, Quentin Bock wrote:
I'm trying to take the user input and let them change the target language
or dest
code:
from deep_translator import GoogleTranslator
import googletrans
import sys
language_list = googletrans.LANGUAGES
print(language_list)
feedback = input("Would you like to translate a sentence of your own?
(yes/no)")
if feedback == 'no':
sys.exit()
while feedback == 'yes':
user_choice = input ("Enter a language (the abbreviation or correctly
spelled name of the language): ").lower()
user_sentence = input("Enter a sentence you want translated: ")
user_translation = GoogleTranslator(source='en',
target=user_choice).translate(user_sentence)
print(user_translation)
feedback = input ("Would you like to translate a sentence of your own?
(yes/no)")
if feedback == 'no':
sys.exit()
when ran, this will bring an error saying that your inputted language is
not supported
why is this?
All I can say is that it works for me!
--
https://mail.python.org/mailman/listinfo/python-list
Re: need help with a translation issue
On Sun, Apr 18, 2021 at 9:58 AM dn via Python-list wrote: > Alternately, what's there to stop some nefarious/stupid user (like me!) > entering "gobbledegook" and complaining that the program fails? "What is the French for fiddle-de-dee?" -- the Red Queen, to Alice (Incidentally, Google attempts to translate it as "violon-de-dee", and declares that the input was indeed in English, disagreeing quite firmly with Alice on both points.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: need help with a translation issue
Longer response:
NB I've not used the system and only quickly reviewed
https://py-googletrans.readthedocs.io/_/downloads/en/documentation/pdf/
NBB I am treating you (and/or other interested-readers) as something of
a 'beginner'. No insult is intended should I appear to be 'talking down'.
On 18/04/2021 10.56, Quentin Bock wrote:
> I'm trying to take the user input and let them change the target language
> or dest
> code:
>
> from deep_translator import GoogleTranslator
> import googletrans
> import sys
>
> language_list = googletrans.LANGUAGES
> print(language_list)
Why print this? Should this output be labelled, or otherwise explained
to the user?
Looking at what is output (yourself), is it a list or a dictionary? When
using it, is the code referring to a list or list of dictionary keys
(country-codes), should it be looking at the country-names, or even both?
(I'm not sure of your intent)
> feedback = input("Would you like to translate a sentence of your own?
> (yes/no)")
>
> if feedback == 'no':
> sys.exit()
When reviewing code: if the same lines are (basically) repeated, is this
(often) a recommendation to employ a function?
Given that the user has kicked-off the program[me], is it necessary to
ask if (s)he wants to translate some text? Will anyone reply "no" at
this point?
Thus, (instead of asking) could we reasonably set "feedback" to "yes"?
That said, what if the user replies "YES" (or some less logical
combination of the same letters)?
> while feedback == 'yes':
Some might suggest that "feedback" should be a boolean value, thus:
while feedback:
> user_choice = input ("Enter a language (the abbreviation or correctly
> spelled name of the language): ").lower()
So, the acceptable response is either the code or the name of the language?
> user_sentence = input("Enter a sentence you want translated: ")
>
> user_translation = GoogleTranslator(source='en',
> target=user_choice).translate(user_sentence)
Yet (according to the docs), the "target" value should be a
language-code, eg 'fr' rather than 'french'.
(remember: I've not used the library, so you're the expert...)
> print(user_translation)
Some would suggest that if "user_translation" is defined on one line and
only ever used on the following, the two lines should be conflated.
(some of us don't agree, especially if it makes testing more awkward)
> feedback = input ("Would you like to translate a sentence of your own?
> (yes/no)")
>
> if feedback == 'no':
> sys.exit()
A UX (User Experience) consideration:
If the user has a series of translations to be made, will (s)he want to
keep repeating the same language/code? Could you code the input
statement to have a default value on the second and ensuing times
through the loop? In this mode, if the user hits Enter without entering
any text-data, the code could 'remember' the language and save
manual-effort.
A thought about design:
This code consists of a loop which has two purposes
1 translate some text
2 continue looping or stop
A useful guide (and testing aid) is "SRP" (the Single Responsibility
Principle) which has a more-technical definition, but let's stick to its
name. Each routine should have only a single task to perform (and should
do it well). Let's consider the first 'purpose':
def translate():
user_choice = input ("Enter...): ").lower()
user_sentence = input("Enter a sentence you want translated: ")
user_translation = GoogleTranslator(source='en',
target=user_choice).translate(user_sentence)
Applying SRP again, we might debate that last line, because it is not
(easily) possible to distinguish between an error at class
instantiation-time (eg "target" is not an acceptable language-code), and
an error at translation-time.
Let's go the next step and separate-out the input functionality. How
about a function like:
def translate( target_language_code, english_text ):
translator = GoogleTranslator( source='en',
target=target_language_code
)
return translator.translate( english_text )
Why?
There is virtue in what appears to be extra, even unnecessary, coding
effort!
This is very easily tested - and can be (even more easily) automatically
tested:
def test_translator( ... ):
assert translate( "fr", "hello" ) == "bonjour"
assert translate( "de", "thank you" ) == "danke schön"
... test for error using non-existent language-code
... test for error using non-English text
I'll leave you to work-out how to encapsulate the inputs into a function
- especially if you plan to implement the default-value idea/service to
users. (!)
The second purpose, after extracting the above, leaves us with a
"control loop" (in real-time systems it is termed an "event loop"), and
pretty-much the code as-is (after any amendments per comments-above).
while feedback:
print( translate() )
feedback = input ("Would you like to translate a sente
