ery useful):
>
> >>> open('foo1','w').encoding
> 'mac-roman'
>
> WTF, indeed.
BTW, I've opened a 3.1 release blocker issue about 'mac-roman' as a
default on OS X. Hard to believe none of us has noticed this up to now!
http://
On 5 Jun, 11:51, Ben Finney wrote:
>
> Actually strings in Python 2.4 or later have the ‘encode’ method, with
> no need for importing extra modules:
>
> =
> $ python -c 'import sys; sys.stdout.write(u"\u03bb\n".encode("utf-8"))'
> λ
>
> $ python -c 'import sys; sys.stdout.write(u"\u03bb\n".enc
Paul Boddie writes:
> The only way to think about this (in Python 2.x, at least) is to
> consider stream and file objects as things which only understand plain
> byte strings. Consequently, use of the codecs module is required if
> receiving/sending Unicode objects from/to streams and files.
Act
On 5 Jun, 03:18, Ron Garret wrote:
>
> According to what I thought I knew about unix (and I had fancied myself
> a bit of an expert until just now) this is impossible. Python is
> obviously picking up a different default encoding when its output is
> being piped to a file, but I always thought on
codec can't encode characters in position
0-2: ordinal not in range(128)
>>> sys.stdout.encoding
'UTF-8'
In python 3.x, of course, the encoding happens automatically but you
still have to tell python, via the "encoding" argument to open, what the
encoding of the file&
"Gabriel Genellina" writes:
> Python knows the terminal encoding (or at least can make a good
> guess), but a file may use *any* encoding you want, completely
> unrelated to your terminal settings.
It may, yes, and the programmer is free to specify any encoding.
> So when stdout is redirected,
In message , Gabriel
Genellina wrote:
> Python knows the terminal encoding (or at least can make a good guess),
> but a file may use *any* encoding you want, completely unrelated to your
> terminal settings.
It should still respect your localization settings, though.
--
http://mail.python.org/
Ned Deily writes:
> $ python2.6 -c 'import sys; print sys.stdout.encoding, \
> sys.stdout.isatty()'
> UTF-8 True
> $ python2.6 -c 'import sys; print sys.stdout.encoding, \
> sys.stdout.isatty()' > foo ; cat foo
> None False
So shouldn't the second case also detect UTF-8? The filesystem knows
i
In article ,
Ron Garret wrote:
> Python 2.6.2 on OS X 10.5.7:
>
> [...@mickey:~]$ echo $LANG
> en_US.UTF-8
> [...@mickey:~]$ cat frob.py
> #!/usr/bin/env python
> print u'\u03BB'
>
> [...@mickey:~]$ ./frob.py
> ª
> [...@mickey:~]$ ./frob.py > foo
> Traceback (most recent call last):
> File
On Thu, Jun 4, 2009 at 10:06 PM, Ben Finney
> wrote:
> Ron Garret writes:
>
> > Python 2.6.2 on OS X 10.5.7:
> >
> > [...@mickey:~]$ echo $LANG
> > en_US.UTF-8
> > [...@mickey:~]$ cat frob.py
> > #!/usr/bin/env python
> > print u'\u03BB'
> >
> > [...@mickey:~]$ ./frob.py
> > ª
> > [...@mickey:~]
Ron Garret writes:
> Python 2.6.2 on OS X 10.5.7:
>
> [...@mickey:~]$ echo $LANG
> en_US.UTF-8
> [...@mickey:~]$ cat frob.py
> #!/usr/bin/env python
> print u'\u03BB'
>
> [...@mickey:~]$ ./frob.py
> ª
> [...@mickey:~]$ ./frob.py > foo
> Traceback (most recent call last):
> File "./frob.py",
In article ,
Lawrence D'Oliveiro wrote:
> In message , Ron
> Garret wrote:
>
> > Python 2.6.2 on OS X 10.5.7:
>
> Same result, Python 2.6.1-3 on Debian Unstable. My $LANG is en_NZ.UTF-8.
>
> > ... I always thought one of the fundamental
> > invariants of unix processes was that there's no wa
En Thu, 04 Jun 2009 22:18:24 -0300, Ron Garret
escribió:
Python 2.6.2 on OS X 10.5.7:
[...@mickey:~]$ echo $LANG
en_US.UTF-8
[...@mickey:~]$ cat frob.py
#!/usr/bin/env python
print u'\u03BB'
[...@mickey:~]$ ./frob.py
ª
[...@mickey:~]$ ./frob.py > foo
Traceback (most recent call last):
Fil
Ron Garret writes:
> According to what I thought I knew about unix (and I had fancied myself
> a bit of an expert until just now) this is impossible. Python is
> obviously picking up a different default encoding when its output is
> being piped to a file, but I always thought one of the funda
In message , Ron
Garret wrote:
> Python 2.6.2 on OS X 10.5.7:
Same result, Python 2.6.1-3 on Debian Unstable. My $LANG is en_NZ.UTF-8.
> ... I always thought one of the fundamental
> invariants of unix processes was that there's no way for a process to
> know what's on the other end of its stdo
Python 2.6.2 on OS X 10.5.7:
[...@mickey:~]$ echo $LANG
en_US.UTF-8
[...@mickey:~]$ cat frob.py
#!/usr/bin/env python
print u'\u03BB'
[...@mickey:~]$ ./frob.py
ª
[...@mickey:~]$ ./frob.py > foo
Traceback (most recent call last):
File "./frob.py", line 2, in
print u'\u03BB'
UnicodeEncodeE
>>> RESTART ========
Just before the "RESTART" line, Windows has announced it killed
pythonw.exe process (I suppose it was a child process).
WTF is happening here? Wasn't fatalError method in the HubErrorHandler
suppos
Paul Rubin:
> Even with that though, at least for me, Python starts feeling really
> scary when the iterators get this complicated. I start wishing for
> a static type system, re-usable iterators, etc.
This is an interesting topic. I agree with you, I too was scared in a
similar situation. The la
Steve Holden wrote:
> James Stroud wrote:
>> [...] I then append the growing list of series generator
>> into the "serieses" list ("serieses" is plural for series if your
>> vocablulary isn't that big).
>>
> Not as big as your ego, apparently ;-) And don't be coming back with any
> argumentses.
Steve Holden wrote:
> James Stroud wrote:
>> [...] I then append the growing list of series generator
>> into the "serieses" list ("serieses" is plural for series if your
>> vocablulary isn't that big).
>>
> Not as big as your ego, apparently ;-) And don't be coming back with any
> argumentses.
James Stroud wrote:
> [...] I then append the growing list of series generator
> into the "serieses" list ("serieses" is plural for series if your
> vocablulary isn't that big).
>
Not as big as your ego, apparently ;-) And don't be coming back with any
argumentses.
regardses
Steve
--
Steve H
Steve Holden wrote:
> James Stroud wrote:
>> [...] I then append the growing list of series generator
>> into the "serieses" list ("serieses" is plural for series if your
>> vocablulary isn't that big).
>>
> Not as big as your ego, apparently ;-) And don't be coming back with any
> argumentses.
James Stroud <[EMAIL PROTECTED]> writes:
> Brilliant suggestion. Worked like a charm. Here is the final product:
Cool, glad it worked out. When writing this type of code I like to
use doctest to spell out some solid examples of what each function is
supposed to do, as part of the function. It's
Paul Rubin wrote:
> Peter Otten <[EMAIL PROTECTED]> writes:
>> You are trying to store a group for later consumption here.
>
> Good catch, the solution is to turn that loop into a generator,
> but then it has to be consumed very carefully.
Brilliant suggestion. Worked like a charm. Here is the f
Peter Otten wrote:
> groupby() is "all you can eat", but "no doggy bag".
Thank you for your clear explanation--a satisfying conclusion to nine
hours of head scratching.
James
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud
Peter Otten <[EMAIL PROTECTED]> writes:
> > Â Â for s_name, series in serialized:
> > Â Â Â grouped = groupby(series, keyfunc)
> > Â Â Â regrouped = ((k, (v[1] for v in g)) for (k,g) in grouped)
> > Â Â Â serieses.append((s_name, regrouped))
>
> You are trying to store a group for later con
James Stroud wrote:
groupby() is "all you can eat", but "no doggy bag".
> def serialize(table, keyer=_keyer,
> selector=_selector,
> keyfunc=_keyfunc,
> series_keyfunc=_series_keyfunc):
> keyed = izip(imap(keyer, table), table)
Paul Rubin wrote:
> James Stroud <[EMAIL PROTECTED]> writes:
>> I can see I didn't explain so well. This one must be a bug if my code
>> looks good to you.
>
> I didn't spot any obvious errors, but I didn't look closely enough
> to say that the code looked good or bad.
>
>> Conclusion: something
James Stroud <[EMAIL PROTECTED]> writes:
> I can see I didn't explain so well. This one must be a bug if my code
> looks good to you.
I didn't spot any obvious errors, but I didn't look closely enough
to say that the code looked good or bad.
> Conclusion: something consumes my generator going fro
James Stroud <[EMAIL PROTECTED]> writes:
> Thank you for your answer, but I am aware of this caveat. Something is
> consuming my generator *before* I iterprint it. Please give it another
> look if you would be so kind.
I'll see if I can look at it some more later, I'm in the middle of
something el
Paul Rubin wrote:
> James Stroud <[EMAIL PROTECTED]> writes:
>> I defined a little debugging function called iterprint:
>>
>> def iterprint(thing): ...
>>for x in thing:
>> iterprint(x)
>
> of course this mutates the thing that is being printed. Try using
> itertools.tee to fork
Paul Rubin wrote:
> James Stroud <[EMAIL PROTECTED]> writes:
>> I defined a little debugging function called iterprint:
>>
>> def iterprint(thing): ...
>>for x in thing:
>> iterprint(x)
>
> of course this mutates the thing that is being printed. Try using
> itertools.tee to fork
James Stroud <[EMAIL PROTECTED]> writes:
> I defined a little debugging function called iterprint:
>
> def iterprint(thing): ...
>for x in thing:
> iterprint(x)
of course this mutates the thing that is being printed. Try using
itertools.tee to fork a copy of the iterator and pri
Hello,
I'm boggled.
I have this function which takes a keyer that keys a table (iterable). I
filter based on these keys, then groupby based on the filtered keys and
a keyfunc. Then, to make the resulting generator behave a little nicer
(no requirement for user to unpack the keys), I strip the
Sergiy wrote:
> print 1 / 2
> print -1 / 2
>
> 0
> -1
>
> correct?
Yes. It works like the floor() function.
>>> import math
>>> math.floor(1.0 / 2)
0.0
>>> math.floor(-1.0 / 2)
-1.0
Shane
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, 26 Apr 2007 21:35:03 +0300, Sergiy <[EMAIL PROTECTED]> wrote:
>print 1 / 2
>print -1 / 2
>
>0
>-1
>
>correct?
Quoting http://www.python.org/doc/lib/typesnumeric.html:
(1)
For (plain or long) integer division, the result is an integer.
The result is always rounded towards minus infin
print 1 / 2
print -1 / 2
0
-1
correct?
--
http://mail.python.org/mailman/listinfo/python-list
[EMAIL PROTECTED] wrote:
> Learn something every day. I take it "646" is an alias for "ascii" (or vice
> versa)?
Usage of "646" as an alias for ASCII is primarily a Sun invention. When
ASCII became an international standard, its standard number became
ISO/IEC 646:1968. It's not *quite* the same a
In article <[EMAIL PROTECTED]>,
"Serge Orlov" <[EMAIL PROTECTED]> wrote:
> Serge Orlov wrote:
> > Ron Garret wrote:
> > > In article <[EMAIL PROTECTED]>,
> > > "Serge Orlov" <[EMAIL PROTECTED]> wrote:
> > >
> > > > Ron Garret wrote:
> > > > > > > I'm using an OS X terminal to ssh to a Linux mach
In article <[EMAIL PROTECTED]>,
"Serge Orlov" <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
> > In article <[EMAIL PROTECTED]>,
> > "Serge Orlov" <[EMAIL PROTECTED]> wrote:
> >
> > > Ron Garret wrote:
> > > > > > I'm using an OS X terminal to ssh to a Linux machine.
> > > > >
> > > > > In theor
[EMAIL PROTECTED] wrote:
> Robert> Because sys.stdout.encoding isn't determined by your Python
> Robert> configuration, but your terminal's.
>
> Learn something every day. I take it "646" is an alias for "ascii" (or vice
> versa)?
>
> % python
> Python 2.4.2 (#1, Feb 23 2006, 12:
[EMAIL PROTECTED] wrote:
> John> Hmm, not that this helps me any :)
>
> import sys
> sys.stdout.encoding
> John> 'cp1252'
>
> Sure it does. You can print Unicode objects which map to cp1252. I assume
> that means you're on Windows or that for some perverse reason you h
John> Hmm, not that this helps me any :)
import sys
sys.stdout.encoding
John> 'cp1252'
Sure it does. You can print Unicode objects which map to cp1252. I assume
that means you're on Windows or that for some perverse reason you have your
Mac's Terminal window set to cp
[EMAIL PROTECTED] wrote:
> Robert> Because sys.stdout.encoding isn't determined by your Python
> Robert> configuration, but your terminal's.
>
> Learn something every day. I take it "646" is an alias for "ascii" (or vice
> versa)?
Hmm, not that this helps me any :)
>>> import sys
>>>
Robert> Because sys.stdout.encoding isn't determined by your Python
Robert> configuration, but your terminal's.
Learn something every day. I take it "646" is an alias for "ascii" (or vice
versa)?
% python
Python 2.4.2 (#1, Feb 23 2006, 12:48:31)
[GCC 3.4.1] on sunos5
Typ
John Salerno wrote:
> AFAIK, I'm all ASCII (at least, I never made explicit changes to the
> default Python install), so how am I able to print out the character?
Because sys.stdout.encoding isn't determined by your Python configuration, but
your terminal's.
--
Robert Kern
"I have come to bel
t encode character u'\xbd' in
>> position 0: ordinal not in range(128)
>
> so stdout on your machine is ascii, and you don't understand why you
> cannot print a non-ascii unicode character to it? wtf?
>
>
>
AFAIK, I'm all ASCII (at least, I never made explicit changes to the
default Python install), so how am I able to print out the character?
--
http://mail.python.org/mailman/listinfo/python-list
cent call last):
>>> File "", line 1, in ?
>>> UnicodeEncodeError: 'ascii' codec can't encode character u'\xbd' in
>>> position 0: ordinal not in range(128)
>> so stdout on your machine is ascii, and you don't understand
Serge Orlov wrote:
> Ron Garret wrote:
> > In article <[EMAIL PROTECTED]>,
> > "Serge Orlov" <[EMAIL PROTECTED]> wrote:
> >
> > > Ron Garret wrote:
> > > > > > I'm using an OS X terminal to ssh to a Linux machine.
> > > > >
> > > > > In theory it should work out of the box. OS X terminal should se
Ron Garret wrote:
> In article <[EMAIL PROTECTED]>,
> "Serge Orlov" <[EMAIL PROTECTED]> wrote:
>
> > Ron Garret wrote:
> > > > > I'm using an OS X terminal to ssh to a Linux machine.
> > > >
> > > > In theory it should work out of the box. OS X terminal should set
> > > > enviromental variable LAN
In article <[EMAIL PROTECTED]>,
"Serge Orlov" <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
> > > > I'm using an OS X terminal to ssh to a Linux machine.
> > >
> > > In theory it should work out of the box. OS X terminal should set
> > > enviromental variable LANG=en_US.utf-8, then ssh should tr
Ron Garret wrote:
> > > I'm using an OS X terminal to ssh to a Linux machine.
> >
> > In theory it should work out of the box. OS X terminal should set
> > enviromental variable LANG=en_US.utf-8, then ssh should transfer this
> > variable to Linux and python will know that your terminal is utf-8.
>
In article <[EMAIL PROTECTED]>,
"Serge Orlov" <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
> > In article <[EMAIL PROTECTED]>,
> > "Serge Orlov" <[EMAIL PROTECTED]> wrote:
> >
> > > Ron Garret wrote:
> > > > In article <[EMAIL PROTECTED]>,
> > > > Robert Kern <[EMAIL PROTECTED]> wrote:
> > >
Ron Garret wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Kern <[EMAIL PROTECTED]> wrote:
>
>>Ron Garret wrote:
>>
>>>I'm using an OS X terminal to ssh to a Linux machine.
>>
>>Click on the "Terminal" menu, then "Window Settings...". Choose "Display"
>>from
>>the combobox. At the bottom you w
Ron Garret wrote:
> In article <[EMAIL PROTECTED]>,
> "Serge Orlov" <[EMAIL PROTECTED]> wrote:
>
> > Ron Garret wrote:
> > > In article <[EMAIL PROTECTED]>,
> > > Robert Kern <[EMAIL PROTECTED]> wrote:
> > >
> > > > Ron Garret wrote:
> > > >
> > > > > I forgot to mention:
> > > > >
> > > > sy
In article <[EMAIL PROTECTED]>,
Robert Kern <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
>
> > I'm using an OS X terminal to ssh to a Linux machine.
>
> Click on the "Terminal" menu, then "Window Settings...". Choose "Display"
> from
> the combobox. At the bottom you will see a combobox titl
Ron Garret wrote:
>
> But what about this:
>
> >>> f2=open('foo','w')
> >>> f2.write(u'\xFF')
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xff' in
> position 0: ordinal not in range(128)
> >>>
>
> That should have nothi
Ron Garret wrote:
> I'm using an OS X terminal to ssh to a Linux machine.
Click on the "Terminal" menu, then "Window Settings...". Choose "Display" from
the combobox. At the bottom you will see a combobox title "Character Set
Encoding". Choose "Unicode (UTF-8)".
> But what about this:
>
f2=
In article <[EMAIL PROTECTED]>,
"Serge Orlov" <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
> > In article <[EMAIL PROTECTED]>,
> > Robert Kern <[EMAIL PROTECTED]> wrote:
> >
> > > Ron Garret wrote:
> > >
> > > > I forgot to mention:
> > > >
> > > sys.getdefaultencoding()
> > > >
> > > > 'u
Ron Garret wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Kern <[EMAIL PROTECTED]> wrote:
>
> > Ron Garret wrote:
> >
> > > I forgot to mention:
> > >
> > sys.getdefaultencoding()
> > >
> > > 'utf-8'
> >
> > A) You shouldn't be able to do that.
>
> What can I say? I can.
>
> > B) Don't do
Ron Garret wrote:
> In article <[EMAIL PROTECTED]>,
> Robert Kern <[EMAIL PROTECTED]> wrote:
>
>>Ron Garret wrote:
>>
>>>I forgot to mention:
>>>
>>>
>>sys.getdefaultencoding()
>>>
>>>'utf-8'
>>
>>A) You shouldn't be able to do that.
>
> What can I say? I can.
See B).
>>B) Don't do that.
In article <[EMAIL PROTECTED]>,
Robert Kern <[EMAIL PROTECTED]> wrote:
> Ron Garret wrote:
>
> > I forgot to mention:
> >
> sys.getdefaultencoding()
> >
> > 'utf-8'
>
> A) You shouldn't be able to do that.
What can I say? I can.
> B) Don't do that.
OK. What should I do instead?
> C)
Ron Garret wrote:
> I forgot to mention:
>
sys.getdefaultencoding()
>
> 'utf-8'
A) You shouldn't be able to do that.
B) Don't do that.
C) It's not relevant to the encoding of stdout which determines how unicode
strings get converted to bytes when printing them:
>>> import sys
>>> sys.stdou
1, in ?
> > UnicodeEncodeError: 'ascii' codec can't encode character u'\xbd' in
> > position 0: ordinal not in range(128)
>
> so stdout on your machine is ascii, and you don't understand why you
> cannot print a non-ascii unicode character to it?
rdinal not in range(128)
so stdout on your machine is ascii, and you don't understand why you
cannot print a non-ascii unicode character to it? wtf?
--
http://mail.python.org/mailman/listinfo/python-list
Ron Garret wrote:
u'\xbd'
> u'\xbd'
print _
> Traceback (most recent call last):
> File "", line 1, in ?
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xbd' in
> position 0: ordinal not in range(128)
Not sure if this really helps you, but:
>>> u'\xbd'
u'\xbd'
>>> pri
>>> u'\xbd'
u'\xbd'
>>> print _
Traceback (most recent call last):
File "", line 1, in ?
UnicodeEncodeError: 'ascii' codec can't encode character u'\xbd' in
position 0: ordinal not in range(128)
>>>
--
http://mail.python.org/mailman/listinfo/python-list
[James Stroud]
> Why do my posts get held for suspcious headers
You're probably trying to post through the python-list email address,
which has had SPAM problems in the past, because the email address has
been used by spammers as a forged from address, meaning the bounces
would go to everyone,
On Tue, 1 Nov 2005, James Stroud wrote:
> Why do my posts get held for suspcious headers and troll Xha Lee gets to post
> all sorts of profanity and ranting without any problem?
>
I like many others have had the same experience.
I recently choose to respond to one of Xha Lee's post and my
Re (
On 2005-11-01, James Stroud <[EMAIL PROTECTED]> wrote:
> On Tuesday 01 November 2005 14:26, Grant Edwards wrote:
>> On 2005-11-01, James Stroud <[EMAIL PROTECTED]> wrote:
>> > Why do my posts get held for suspcious headers
> ...
>> Held? It's not a moderated group...
>
> And I quoteth (that's King
happens to me too.
--
http://mail.python.org/mailman/listinfo/python-list
On Tuesday 01 November 2005 14:26, Grant Edwards wrote:
> On 2005-11-01, James Stroud <[EMAIL PROTECTED]> wrote:
> > Why do my posts get held for suspcious headers
...
> Held? It's not a moderated group...
And I quoteth (that's King James for "cuteth-and-pasteth"):
> Your mail to 'Python-list' w
On 2005-11-01, James Stroud <[EMAIL PROTECTED]> wrote:
> Why do my posts get held for suspcious headers and troll Xha
> Lee gets to post all sorts of profanity and ranting without
> any problem?
Held? It's not a moderated group...
--
Grant Edwards grante Yow! I'm
On 11/1/05, James Stroud <[EMAIL PROTECTED]> wrote:
Why do my posts get held for suspcious headers and troll Xha Lee gets to postall sorts of profanity and ranting without any problem?--James StroudUCLA-DOE Institute for Genomics and ProteomicsBox 951570
Los Angeles, CA 90095http://www.jamesstroud.
Why do my posts get held for suspcious headers and troll Xha Lee gets to post
all sorts of profanity and ranting without any problem?
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud.com/
--
http://mail.python.org/mailman/lis
True, wasn't thinking. This will affect get() as well. My problem was a
slightly different problem.
In your case you would have got what you wanted if get()/items()
instead of being implemented as:
.try:
.value = d[option]
.except KeyError:
.raise NoOptionE
[EMAIL PROTECTED] wrote:
To avoid this, you need to write something like:
. list = []
. for key in configuration.options("core"):
. list.append((key,configuration.get("core",substitution))
. print list
This cause me problems for a different reason, ie., that user vars keys
appear in what ite
Sort of hard to explain, but if you put another:
list = configuration.items("core")
print list
at the end of the script, you will find that the original config hasn't
been changed.
It is a quirk of how the items() method is implemented using 'yield'
that means that
you see what you do.
In partic
I'm not sure if this is a real problem or if I have been staring at code
too long. given this code
#!/usr/bin/python
from ConfigParser import *
configuration_file = "test.conf"
substitution = {"xyzzy":"maze"}
configuration = SafeConfigParser()
configuration.readfp(file(configuration_file))
list
79 matches
Mail list logo
