Pyside does something weird with locale - unicode

here are the relevant code lines for a unicode/pyside related problem :
#!/usr/bin/env python
# coding=utf-8
...
msgBox = QtGui.QMessageBox()
msgBox.setText('é')
print 'é'
....
The print does what it should, implying my locale is utf-8, and printenv confirms it. On the other hand, the msgBox shows 'é', unless I prefix the string with 'u'. Is that normal, and do I really have to prefix every string with u in order to use Pyside, when python never raises a problem?
Thanks for your attention.

In Python 2.X there are two data types for strings: byte code and unicode. With u you choose unicode with nothing you choose byte code. If you print bytes('é') you see where PySide/PyQt get their data from. So it probably is normal.
The easy way out is using Python 3.X which just has unicode and won't bother you with the difference.
Not sure who is actually doing something that shouldn't be done, the print function Python 2.X or PySide/PyQt for Python 2.X, so I make it community wiki.

Related

How do I save a Save/Load a text file in Red

I already know how to do this, but I figured I would go ahead and ask since the Rebol documentation is offline today and so in the future others will have an easier time finding out how.
In a nutshell, use read for reading a text file (a string will be returned) and write for writing a string down to a file. For example:
write %hello.txt "Hello World!"
print read %hello.txt
Such text-mode I/O relies on UTF-8 for reading/writing, other encodings will be supported in the future.
Additionally, you can use /binary refinement for both functions to switch to binary mode. You can also use the higher-level load and save counterparts, which will try to encode/decode the data using one of the available codecs (UTF-8 <=> Red values, JPG/PNG/GIF/BMP <=> image! value).
Use help followed by a function name for more info.

Strawberry Perl not recognising special variable for OSNAME

I recently upgraded Strawberry Perl from version 5.14.1.1-32bit to 5.24.0-64bit on my PC running Windows 7. I have a perl script I run under both Windows and Linux, and when I was using the old version the command
use if $^O eq 'MSWin32' , 'Win32::Console::ANSI';
worked, but now that I've upgraded I get the error message
Unrecognized character \x0F; marked by <-- HERE after use if $<-- HERE near column9 at p:\bin\abc.pl line 31.
Does anyone know what changed, and how I can get the new version of Strawberry Perl to accept the command? Thanks in advance to all who respond.
Your code contains the Shift In control character (0x0F), also known as "Control-O", instead of the characters ^ and O. This works in older versions of Perl but was deprecated in version 5.20.0:
Literal control characters in variable names
This deprecation affects things like $\cT, where \cT is a literal control (such as a NAK or NEGATIVE ACKNOWLEDGE character) in the source code. Surprisingly, it appears that originally this was intended as the canonical way of accessing variables like $^T, with the caret form only being added as an alternative.
The literal control form is being deprecated for two main reasons. It has what are likely unfixable bugs, such as $\cI not working as an alias for $^I, and their usage not being portable to non-ASCII platforms: While $^T will work everywhere, \cT is whitespace in EBCDIC. [perl #119123]
As of 5.24.0, using a variable name containing non-graphical ASCII control characters results in a syntax error.

Execute Commands in the Linux Commandline [Lazarus / Free Pascal]

I have a problem. I want to execute some commands in the Commandline of linux. I tested TProcess (So i am using Lazarus) but now when i am starting the programm, there is nothing, wich the Program do.
Here is my Code:
uses [...], unix, process;
[...]
var LE_Path: TLabeledEdit;
[...]
Pro1:=TProcess.Create(nil);
Pro1.CommandLine:=(('sudo open'+LE_Path.Text));
Pro1.Options := Pro1.Options; //Here i used Options before
Pro1.Execute;
With this Program, i want to open Files with sudo (The Programm is running on the User Interface)
->Sorry for my Bad English; Sorry for fails in the Question: I am using StackOverflow the first time.
I guess the solution was a missing space char?
Change
Pro1.CommandLine:=(('sudo open'+LE_Path.Text));
to
Pro1.CommandLine:=(('sudo open '+LE_Path.Text));
# ----------------------------^--- added this space char.
But if you're a beginner programmer, my other comments are still worth considering:
trying to use sudo in your first bit of code may be adding a whole extra set of problems. SO... Get something easier to work first, maybe
/bin/ls -l /path/to/some/dir/that/has/only/a/few/files.
find out how to print a statement that will be executed. This is the most basic form of debugging and any language should support that.
Your english communicated your problem well enough, and by including sample code and reasonable (not perfect) problem description "we" were able to help you. In general, a good question contains the fewest number of steps to re-create the problem. OR, if you're trying to manipulate data,
a. small sample input,
b. sample output from that same input
c. your "best" code you have tried
d. your current output
e. your thoughts about why it is not working
AND comments to indicate generally other things you have tried.

Need to color terminal's output produced with print command Term::ANSIColor

Here is what I have:
use Term::ANSIColor;
print "Blah!".color("green");
The output is
Test←[32m
What am I missing?
The terminal program you are using does not support the ECMA-48 color escape codes. So it does not give them any special treatment, and instead outputs the characters as-is.
What you are missing: a terminal that does. xterm, libvte, putty, are just a few to name that do.
Are you on Windows? I'm fairly certain that the Windows shell isn't compliant with the color codes used by the module.
Actually, it says so right there on the module's documentation.
Note that not all displays are ISO 6429-compliant, or even X3.64-compliant (or are even attempting to be so). This module will not work as expected on displays that do not honor these escape sequences, such as cmd.exe, 4nt.exe, and command.com under either Windows NT or Windows 2000. They may just be ignored, or they may display as an ESC character followed by some apparent garbage.
EDIT:
An addendum to my comment:
C:\>perl -MWin32::Console::ANSI -MTerm::ANSIColor -e "print color(\"green\"), 'test', color(\"reset\");"
Works just fine on Windows XP, Perl 5.12.1, so there's your workaround.

Python 3, is using sys.stdout.buffer.write() good style?

After I learned about reading unicode files in Python 3.0 web script, now it's time for me to learn using print() with unicode.
I searched for writing unicode, for example this question explains that you can't write unicode characters to non-unicode console. However, in my case, the output is given to Apache and I am sure that it is capable of handling unicode text. For some reason, however, the stdout of my web script is in ascii.
Obviously, if I was opening a file to write myself, I would do something like
open(filename, 'w', encoding='utf8')
but since I'm given an open stream, I resorted to using
sys.stdout.buffer.write(mytext.encode('utf-8'))
and everything seems to work. Does this violate some rule of good behavior or has any unintended consequences?
I don't think you're breaking any rule, but
sys.stdout = codecs.EncodedFile(sys.stdout, 'utf8')
looks like it might be handier / less clunky.
Edit: per comments, this isn't quite right -- #Miles gave the right variant (thanks!):
sys.stdout = codecs.getwriter('utf8')(sys.stdout.buffer)
Edit: if you can arrange for environment variable PYTHONIOENCODING to be set to utf8 when Apache starts your script, that would be even better, making sys.stdout be set to utf8 automatically; but if that's unfeasible or impractical the codecs solution stands.
This is an old answer but I'll add my version here since I first ventured here before finding my solution.
One of the issues with codecs.getwriter is if you are running a script of sorts, the output will be buffered (whereas normally python stdout prints after every line).
sys.stdout in the console is a IOTextWrapper, so my solution uses that. This also allows you to set line_buffering=True or False.
For example, to set stdout to, instead of erroring, backslash encode all output:
sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding=sys.stdout.encoding,
errors="backslashreplace", line_buffering=True)
To force a specific encoding (in this case utf8):
sys.stdout = io.TextIOWrapper(sys.stdout.detach(), encoding="utf8",
line_buffering=True)
A note, calling sys.stdout.detach() will close the underlying buffer. Some modules use sys.__stdout__, which is just an alias for sys.stdout, so you may want to set that as well
sys.stdout = sys.__stdout__ = io.TextIOWrapper(sys.stdout.detach(), encoding=sys.stdout.encoding, errors="backslashreplace", line_buffering=True)
sys.stderr = sys.__stderr__ = io.TextIOWrapper(sys.stderr.detach(), encoding=sys.stdout.encoding, errors="backslashreplace", line_buffering=True)