Re: [Python-ideas] Debugging: some problems and possible solutions
Good morning,
I read about a "time machine" debugger a long time ago. The debugger
would collect all the information of all the calls and the programmer
can just execute the code without breakpoints. Later, the programmer can
follow the evolution of a variable until it reaches an erroneous value.
I've never worked with that and it sounds really memory intensive, but
the examples were quite interesting.
When you are in a loop, you want to break at a certain iteration.
When you are in a recursive function, you want to stop at the right point.
etc.
Cheers,
Hans
On 03/10/18 16:51, Jonathan Fine wrote:
This thread is about debugging. I suggest we start by collecting
problems and possible solutions. And that after about a week of that,
we start discussing what we've gathered.
We already have a problem and possible solution, provided by Eric
Smith and Larry Hastings.
TITLE: f-string "debug" conversion
URL: https://mail.python.org/pipermail/python-ideas/2018-October/053956.html
PROBLEM
Writing
print('value = ', value)
is tedious, particularly for more complicated expressions, such as
print('big_array[5:20] =', big_array[5:20])
POSSIBLE SOLUTION
For f-strings, we add a !d conversion operator, which produces the
text of an expression followed by its value. Thus, the two previous
examples can be written more concisely as
print(f'{value !d}')
print(f'{big_array[5:20] !d}')
I suggest for the moment that we just gather problem-solution pairs,
much as above. I think they'll be between 5 and 15 such pairs. I'll
post one to the current discussion thread in an hour or so.
And that after about a week, we move to discussing what we have.
Finally, many thanks to Eric and Larry for their useful contribution
to the important problem of debugging.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] "while:" for the loop
On 26/09/18 18:23, Michael Selik wrote: Guido has repeatedly (haha) rejected this proposal [0]. He has written that he considered it, but decided that in practical code one almost always loops over data, and does not want an arbitrary number of iterations. The range object solves this problem. Years ago, I proposed a do...loop. Guido rejected that. As an aside, here's a pattern you can use for do...loops. def do_loop(): if True: return True return False while do_loop(): pass Cheers, Hans ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Moving to another forum system where
I don’t think its unreasonable to point out that it’s a *mailing list*. A firehose of email is generally a sign of good health of a mailing list. Even so, there are mitigations to the firehose effect, including, but not limited to digests and setting up your client to move mailing list posts directly to a folder (including the trash for threads you don’t want to follow). I don't understand how one can sign up for a mass email discussion forum, and be surprised that it increased the amount of email they receive. It's kind of the point of the medium. Right you are, Alex. I don’t think its unreasonable to point out that the title of this thread is "Moving to another forum". If you want to contribute Python Ideas you *have to* subscribe to the mailing list. Let me just say that I second the idea of moving to another forum. I already move most mail automatically to the trash folder and read it there before eliminating it. My inbox contains exactly four emails at the moment, FYI. Cheers, Hans ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Moving to another forum system where
Just an observation. I've been a member of this mailing list since (literally) five days ago and I am receiving a busload of emails. I'm a member of Stackoverflow and I visit the Q site daily... and I hardly ever receive emails. I suspect Discourse would be a good match for these discussions (although I have no experience whatsoever with it). TL;DR; I would appreciate receiving less mail. Cheers, Hans ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n
On 17/09/18 20:10, Eric V. Smith wrote: See also PEP 501, which could be used for i18n. My first idea was to propose a t-string (for translatable string). Cheers, Hans ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n
On 17/09/18 19:42, Stephen J. Turnbull wrote:
> That's why I would like to see a parameter that can be passed to
> the f-string.
This doesn't make sense to me.
If I get a request in English, I need to return English.
If I get a request in French, I need to return French.
# At the start of the app, the languages get loaded in memory.
translate = translation('app','.locale')
translate.install()
es = translation('app','.locale',languages=['es'])
es.install()
# Get the preferred user language from the http request T(_('Hello {user}...'),
user_language,user=user)
def T(translatable_string, language=None, *args, **kwargs):
if 'es' == language:
# Return translated, formatted string return
es.gettext(translatable_string).format(**kwargs)
# Default, return formatted string return
translatable_string.format(**kwargs)
Such configurations are long-lasting.
If it is for the whole app, yes. Not if it is just the request.
1. No translation, just a regular f-string.
2. App translation. The f-string gets translated to the configured
language. Long lasting configuration.
3. On the fly translation. The string gets translated to the language
passed as an argument as required.
What could work is an extension to the formatting language. I suggest
abusing the *conversion flag*. (It's an abuse because I'm going to
apply it to the whole f-string, while the current Language Reference
says it's applied to the value being formatted.[1]) This flag would only
be allowed as the first item in the string. The idea is that
`f"{lang!g}Hello, {user}!"` would be interpreted as
Excellent. The syntax is unimportant to me.
Cheers,
Hans
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n - How about using PEP 501?
I don't see how this immediately helps the OP, who wants a *literal*
expression that automatically invokes the translation machinery as
well as the interpolation machinery.
Actually, no, I do not want the expression to be automatically
translated at compile time. It should be translated at run-time. There
are three situations.
1. No translation, just a regular f-string.
2. App translation. The f-string gets translated to the configured language.
3. On the fly translation. The string gets translated to the language
passed as an argument as required.
In code, this would be.
1. f'Hi {user}'
2. f'{!g}Hi {user}'
3. f'{lang!g}Hi {user}'
Cases 2 and 3 need some additional code, just like with gettext.
I'm sorry if that wasn't clear from the start. All I want is the code to
be simpler to write and maintain. I do not want to have complicated
parsing for the compiler.
Another way forward could be a preprocessor. All this can be done with a fairly
simple script using parso.
This is probably the idea.
Cheers,
Hans
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n
On 17/09/18 09:53, Niki Spahiev wrote:
Is it possible to use f-strings when making multilingual software?
When i write non-hobby software translation is hard requirement.
At this moment, it seems that this is not possible.
My use case is not very unique and that's why I wrote the proposal in
the first place. I'm working on a web server / application server. On
the web, you have to take the users preferences into account, including
language. If a user has the navigator configured for English, I have to
return English (if I am doing i18n).
That's why I would like to see a parameter that can be passed to the
f-string.
I don't think this should be too problematic, really.
pygettext.py extracts strings surrounded by _('') My proposal would be
to do that with f-strings. Let pygettext.py extract f-strings.
The compiler can then rewrite these to normal unicode strings. For
instance: f'Hi {user}'.language('es') would become T(_('Hi {user}'),
'es', user=user)
My first email had pseudo-code. This is my working function.
def T(translatable_string, language=None, *args, **kwargs):
if args:
print(args)
if 'es' == language:
# Return translated, formatted string return
es.gettext(translatable_string).format(**kwargs)
# Default, return formatted string return
translatable_string.format(**kwargs)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Combine f-strings with i18n
f-strings & pythonic
- Simple is better than complex.
- Flat is better than nested. (I think this applies)
- Readability counts.
- If the implementation is easy to explain, it may be a good idea.
Just saying.
Cheers,
Hans
On 14/09/18 11:33, Chris Angelico wrote:
On Fri, Sep 14, 2018 at 7:02 PM, Hans Polak wrote:
I have recently updated my code to use the more pythonic f-string instead of
'{}'.format()
Well there's your problem right there. Don't change your string
formatting choice on that basis. F-strings aren't "more Pythonic" than
either .format() or percent-formatting; all three of them are
supported for good reasons.
For i18n, I think .format() is probably your best bet. Trying to mess
with f-strings to give them methods is a path of great hairiness, as
they are not actually objects (they're expressions).
ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Combine f-strings with i18n
I have recently updated my code to use the more pythonic f-string
instead of '{}'.format()
Now, I want to start on the road to multilingual internationalization,
and I run into two problems. The first problem is that f-strings do not
combine with i18n. I have to revert to the '{}'.format() style.
The second problem is that I need to translate strings on the fly. I
propose to add a f''.language() method to the f-string format.
Example:
user = 'Pedro'
f'Hi {user}' would be translated to 'Hola Pedro' if the locale were set
to Spanish.
f'Hi {user}'.language('es_ES') would be translated in the same way.
To extract translatable strings from the source code, the source code
could contain a 'HAS_LOCALES' flag (or something similar) at the top of
the code. This way, the pygettext.py program would know that
translatable f-strings are within the code.
Rationale:
More pythonic. At this moment, _('').format() is the way to go, so I
would need to wrap another call around that: T(_(''), args, 'es_ES')
<===This is an ugly hack.
# Set the _() function to return the same string
_ = lambda s: s
es = gettext.translation('myapplication', languages=['es_ES'])
def T(translatable_string, args_dictionary = None, language = None)
if 'es_ES' == language:
# Return translated, formatted string
return es.gettext(translatable_string).format(args)
# Default, return formatted string
return translatable_string.format(args)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
