On Mon, May 25, 2015 at 09:33:06AM +, Donal Duane wrote:
>
> Hi Python Users,
>
> I was hoping you might be able to assist me with a query:
>
> 2 Questions:
>
>
> 1. Could Python 3.2, when compiled against OpenSSL 1.0.0j, be
> affected by the poodle
On Mon, May 25, 2015 at 7:33 PM, Donal Duane wrote:
>
> Hi Python Users,
>
> I was hoping you might be able to assist me with a query:
>
> 2 Questions:
>
> 1. Could Python 3.2, when compiled against OpenSSL 1.0.0j, be affected
> by the poodle bug? https:
This showed up on Python list.
--- Forwarded Message
Return-Path:
Received: from mail.python.org (mail.python.org [82.94.164.166])
From: Donal Duane
To: "python-list@python.org"
Subject: Query on Python 3.2 and supported OpenSSL Versions
Cc: Alex Ying ,
Anthony McM
Hi Python Users,
I was hoping you might be able to assist me with a query:
2 Questions:
1. Could Python 3.2, when compiled against OpenSSL 1.0.0j, be affected by
the poodle bug? https://www.openssl.org/~bodo/ssl-poodle.pdf
2. If yes - are the following OpenSSL versions
I am working on drawing map from shape file in Python 3.2 basemap.
But, the longitude values at the bottom axis are only shown partially. Also,
all latitude values are missing.
Here is my python code.
import shapefile as sf
import sys
import numpy as np
import matplotlib.pylab as plt
from
On 06/05/2014 05:02 PM, Steven D'Aprano wrote:
>[...]
> But Linux Unicode support is much better than Windows. Unicode support in
> Windows is crippled by continued reliance on legacy code pages, and by
> the assumption deep inside the Windows APIs that Unicode means "16 bit
> characters". See,
On Sat, Jun 7, 2014 at 7:18 AM, Denis McMahon wrote:
>> into the lowest seven bits of a byte, with the high byte left clear.
>
> high BIT left clear.
That thing. Unless you have bytes inside bytes (byteception?), you'll
only have room for one high bit. Some day I'll get my brain and my
fingers to
On Sat, 07 Jun 2014 01:50:50 +1000, Chris Angelico wrote:
> Yes and no. "ASCII" means two things:
ASCII means: American Standard Code for Information Interchange aka ASA
Standard X3.4-1963
> into the lowest seven bits of a byte, with the high byte left clear.
high BIT left clear.
--
Denis Mc
On 6/6/14 1:11 PM, Marko Rauhamaa wrote:
Steven D'Aprano :
On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote:
Unicode, like ASCII, is a code. Representing text in unicode is
encoding.
A Unicode string as an abstract data type has no encoding.
Unicode itself is an encoding. See it in
On Sat, Jun 7, 2014 at 3:13 AM, Rustom Mody wrote:
> On Friday, June 6, 2014 10:32:47 PM UTC+5:30, Marko Rauhamaa wrote:
>> Chris Angelico :
>
>> > "ASCII" means two things: Firstly, it's a mapping from the letter A to
>> > the number 65, from the exclamation mark to 33, from the backslash to
>> >
On Sat, Jun 7, 2014 at 3:04 AM, Rustom Mody wrote:
>> ASCII was once your one companion, it was all that mattered. ASCII was
>> once a friendly encoding, then your world was shattered. Wishing it
>> were somehow here again, wishing it were somehow near... sometimes it
>> seemed, if you just dreame
Marko Rauhamaa :
> Far from it. It is a mapping from symbols to integers. The symbols are
> the Platonic ones.
Well, of course, even the symbols are a code. Letters code sounds and
digits code numbers.
And the sounds and numbers code ideas. Now we are getting close to being
truly Platonic.
Mar
On Sat, Jun 7, 2014 at 3:11 AM, Marko Rauhamaa wrote:
> Encoding is not tied to bytes or even computers. People can speak in
> code, after all.
Obligatory: http://xkcd.com/257/
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Friday, June 6, 2014 10:32:47 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> > "ASCII" means two things: Firstly, it's a mapping from the letter A to
> > the number 65, from the exclamation mark to 33, from the backslash to
> > 92, and so on. And secondly, it's an encoding of those num
Steven D'Aprano :
> On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote:
>> Unicode, like ASCII, is a code. Representing text in unicode is
>> encoding.
>
> A Unicode string as an abstract data type has no encoding.
Unicode itself is an encoding. See it in action here:
72 101 108 108 11
On Friday, June 6, 2014 10:18:41 PM UTC+5:30, Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 2:21 AM, Rustom Mody wrote:
> > Combine that with Chris':
> >> Yes and no. "ASCII" means two things: Firstly, it's a mapping from the
> >> letter A to the number 65, from the exclamation mark to 33, from t
Chris Angelico :
> "ASCII" means two things: Firstly, it's a mapping from the letter A to
> the number 65, from the exclamation mark to 33, from the backslash to
> 92, and so on. And secondly, it's an encoding of those numbers into
> the lowest seven bits of a byte, with the high byte left clear.
On Sat, Jun 7, 2014 at 2:21 AM, Rustom Mody wrote:
> Combine that with Chris':
>
>> Yes and no. "ASCII" means two things: Firstly, it's a mapping from the
>> letter A to the number 65, from the exclamation mark to 33, from the
>> backslash to 92, and so on. And secondly, it's an encoding of those
On Friday, June 6, 2014 9:27:51 PM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote:
> > Michael Torri:
> >> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote:
> >>> Ethan Furman :
> ASCII is *not* the state of "this string has no encoding" -- that
>
On Fri, 06 Jun 2014 18:32:39 +0300, Marko Rauhamaa wrote:
> Michael Torrie :
>
>> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote:
>>> Ethan Furman :
ASCII is *not* the state of "this string has no encoding" -- that
would be Unicode; a Unicode string, as a data type, has no encoding.
>>>
On Sat, Jun 7, 2014 at 1:32 AM, Marko Rauhamaa wrote:
> Michael Torrie :
>
>> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote:
>>> Ethan Furman :
ASCII is *not* the state of "this string has no encoding" -- that
would be Unicode; a Unicode string, as a data type, has no encoding.
>>>
>>> Hu
Michael Torrie :
> On 06/06/2014 08:10 AM, Marko Rauhamaa wrote:
>> Ethan Furman :
>>> ASCII is *not* the state of "this string has no encoding" -- that
>>> would be Unicode; a Unicode string, as a data type, has no encoding.
>>
>> Huh?
>
> [...]
>
> What part of his statement are you saying "Huh
On Fri, Jun 6, 2014 at 11:24 PM, Ethan Furman wrote:
> On 06/05/2014 11:30 AM, Marko Rauhamaa wrote:
>>
>>
>> How text is represented is very different from whether text is a
>> fundamental data type. A fundamental text file is such that ordinary
>> operating system facilities can't see inside the
On 06/06/2014 08:10 AM, Marko Rauhamaa wrote:
> Ethan Furman :
>> ASCII is *not* the state of "this string has no encoding" -- that
>> would be Unicode; a Unicode string, as a data type, has no encoding.
>
> Huh?
It's this very fact that trips of JMF in his rants about FSR. Thank you
to Ethan fo
On 06/05/2014 09:32 AM, Steven D'Aprano wrote:
But whatever the situation, and despite our differences of opinion about
Unicode, THANK YOU for having updated ReportLabs to 3.3.
+1000
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
Ethan Furman :
> On 06/05/2014 11:30 AM, Marko Rauhamaa wrote:
>> A fundamental text file is such that ordinary operating system
>> facilities can't see inside the black box (that is, they are *not*
>> encoded as far as the applications go).
>
> Of course they are.
How would you know?
> It may b
On 06/05/2014 11:30 AM, Marko Rauhamaa wrote:
>
How text is represented is very different from whether text is a
fundamental data type. A fundamental text file is such that ordinary
operating system facilities can't see inside the black box (that is,
they are *not* encoded as far as the applicati
Steven D'Aprano :
> Incorrect. Linux presents data as text all the time. Look at the prompt:
> its treated as text, not numbers.
Of course there is a textual human interface. However, from the point of
view of virtually every OS component, it's bytes.
> Consider:
>
> [steve@ando ~]$ echo -e '\
On Fri, 06 Jun 2014 02:21:54 +0300, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> In any case, I reject your premise. ALL data types are constructed on
>> top of bytes,
>
> Only in a very dull sense.
I agree with you that this is a very dull, unimportant sense. And I think
it's dullness appli
On 05/06/2014 18:16, Ian Kelly wrote:
.
How should e.g. bytes.upper() be implemented then? The correct
behavior is entirely dependent on the encoding. Python 2 just assumes
ASCII, which at best will correctly upper-case some subset of the
string and leave the rest unchanged, and at wor
Marko Rauhamaa writes:
> Steven D'Aprano :
>
>> Nevertheless, there are important abstractions that are written on top
>> of the bytes layer, and in the Unix and Linux world, the most
>> important abstraction is *text*. In the Unix world, text formats and
>> text processing is much more common in
On 06/05/2014 04:30 PM, Marko Rauhamaa wrote:
What I'm afraid of is that the Python developers are reserving the right
to remove the buffer and detach attributes from the standard streams in
a future version.
Being afraid is silly. If you have a question, ask it.
--
~Ethan~
--
https://mail.
On Friday, June 6, 2014 8:50:57 AM UTC+5:30, Chris Angelico wrote:
> kernel doesn't actually do *anything* with the string, it just passes
> it right along to the file system.
Which is what Marko (and others like Armin) are asking of python
(treated as a processing 'kernel'):
"I know what I am do
On Fri, Jun 6, 2014 at 1:11 PM, Rustom Mody wrote:
> All character strings, including
> | filenames, are treated by the kernel in such a way that THEY
> | APPEAR TO IT ONLY AS STRINGS OF BYTES.
Yep, the real issue here is file systems, not the kernel. But yes,
this is one of the very few places w
On Friday, June 6, 2014 4:22:22 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Jun 6, 2014 at 8:35 AM, Rustom Mody wrote:
> > And then ask how Linux (in your and Stallman's sense) differs from
> > Windows in how the filesystem handles things like filenames?
> What are you testing of the kernel? Mos
On 6/5/2014 7:30 PM, Marko Rauhamaa wrote:
Steven D'Aprano :
"Can be replaced" by who? By the Python developers? By me? By random
library calls?
By you. sys.stdout and friends are writable. Any code you call may
have replaced them with another file-like object, and you should
honour that.
I
On Fri, Jun 6, 2014 at 9:30 AM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>>> "Can be replaced" by who? By the Python developers? By me? By random
>>> library calls?
>>
>> By you. sys.stdout and friends are writable. Any code you call may
>> have replaced them with another file-like object, and
Steven D'Aprano :
>> "Can be replaced" by who? By the Python developers? By me? By random
>> library calls?
>
> By you. sys.stdout and friends are writable. Any code you call may
> have replaced them with another file-like object, and you should
> honour that.
I can of course overwrite even sys a
Steven D'Aprano :
> In any case, I reject your premise. ALL data types are constructed on
> top of bytes,
Only in a very dull sense.
> and so long as you allow applications *any way* to coerce data types
> to different data types, you allow them to see "inside the black box".
I can't see the by
On Thu, 05 Jun 2014 23:21:35 +0300, Marko Rauhamaa wrote:
> Terry Reedy :
>
>> On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
>>> Chris Angelico :
>>>
If the standard streams are so crucial, why are their most obvious
interfaces insignificant to you?
>>>
>>> I want the standard streams to c
On Thu, 05 Jun 2014 21:30:11 +0300, Marko Rauhamaa wrote:
> Terry Reedy :
>
>> Different OSes *do* have different assumptions. Both MacOSX and current
>> Windows use (UCS-2 or) UTF-16 for text.
>
> Linux can use anything for text; UTF-8 has become a de-facto standard.
>
> How text is represente
On Fri, Jun 6, 2014 at 8:35 AM, Rustom Mody wrote:
> On Thursday, June 5, 2014 10:58:43 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Jun 6, 2014 at 2:52 AM, Marko Rauhamaa wrote:
>> > That linux text is not the same thing as Python's text. Conceptually,
>> > Python text is a sequence of 32-bit in
On Thursday, June 5, 2014 10:58:43 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jun 6, 2014 at 2:52 AM, Marko Rauhamaa wrote:
> > That linux text is not the same thing as Python's text. Conceptually,
> > Python text is a sequence of 32-bit integers. Linux text is a sequence
> > of 8-bit integers.
On 6/5/2014 4:21 PM, Marko Rauhamaa wrote:
Terry Reedy :
On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
Chris Angelico :
If the standard streams are so crucial, why are their most obvious
interfaces insignificant to you?
I want the standard streams to consume and produce bytes.
Easy. Read th
Terry Reedy :
> On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
>> Chris Angelico :
>>
>>> If the standard streams are so crucial, why are their most obvious
>>> interfaces insignificant to you?
>>
>> I want the standard streams to consume and produce bytes.
>
> Easy. Read the manual entry for stdxxx.
On 6/5/2014 5:53 AM, Marko Rauhamaa wrote:
Chris Angelico :
If the standard streams are so crucial, why are their most obvious
interfaces insignificant to you?
I want the standard streams to consume and produce bytes.
Easy. Read the manual entry for stdxxx. "To write or read binary data
fr
Terry Reedy :
> Different OSes *do* have different assumptions. Both MacOSX and
> current Windows use (UCS-2 or) UTF-16 for text.
Linux can use anything for text; UTF-8 has become a de-facto standard.
How text is represented is very different from whether text is a
fundamental data type. A funda
On 6/5/2014 10:45 AM, Marko Rauhamaa wrote:
Mostly I'm saying Python3 will not be able to hide the fact that linux
data consists of bytes. It shouldn't even try. The linux OS outside the
Python process talks bytes, not strings.
A text file is a binary file wrapped with a codex to translate to
On Fri, Jun 6, 2014 at 2:54 AM, Rustom Mody wrote:
> On Thursday, June 5, 2014 9:42:28 PM UTC+5:30, Chris Angelico wrote:
>> On Fri, Jun 6, 2014 at 1:33 AM, Steven D'Aprano wrote:
>> > In the Unix world, text formats and text
>> > processing is much more common in user-space apps than binary proce
On Fri, Jun 6, 2014 at 2:52 AM, Marko Rauhamaa wrote:
> That linux text is not the same thing as Python's text. Conceptually,
> Python text is a sequence of 32-bit integers. Linux text is a sequence
> of 8-bit integers.
Point of terminology: Linux is the kernel, everything you say below
here is t
On Thu, Jun 5, 2014 at 10:17 AM, Robin Becker wrote:
> in python 2 str and unicode were much more comparable. On balance I think
> just reversing them ie str --> bytes and unicode --> str was probably the
> right thing to do if the default conversions had been turned off. However
> making bytes a
On Fri, Jun 6, 2014 at 2:17 AM, Robin Becker wrote:
> in python 2 str and unicode were much more comparable. On balance I think
> just reversing them ie str --> bytes and unicode --> str was probably the
> right thing to do if the default conversions had been turned off. However
> making bytes a c
On Thursday, June 5, 2014 9:42:28 PM UTC+5:30, Chris Angelico wrote:
> On Fri, Jun 6, 2014 at 1:33 AM, Steven D'Aprano wrote:
> > In the Unix world, text formats and text
> > processing is much more common in user-space apps than binary processing.
> > Perhaps the definitive explanation and celebra
Steven D'Aprano :
> Nevertheless, there are important abstractions that are written on top
> of the bytes layer, and in the Unix and Linux world, the most
> important abstraction is *text*. In the Unix world, text formats and
> text processing is much more common in user-space apps than binary
> p
On Thu, 05 Jun 2014 17:17:05 +0100, Robin Becker wrote:
> Bytes are the underlying
> concept and should have remained so for simplicity's sake.
Bytes are the underlying concept for classes too. Do you think that an
opaque unstructured blob of bytes is "simpler" to use than a class? How
would an
On Thu, 05 Jun 2014 16:37:23 +0100, Robin Becker wrote:
> In python 3 byte strings
> are second class which I think is wrong
It certainly is wrong. bytes are just as much a first-class built-in type
as list, int, float, bool, set, tuple and str.
There may be missing functionality (relatively ea
On 05/06/2014 16:50, Chris Angelico wrote:
..
I wouldn't say they're second-class; it's more that the bytes type was
considered to be more like a list of ints than like a Unicode string,
and now that there are a few years' worth of real-world usage
information to learn from, it's known t
On Fri, Jun 6, 2014 at 1:33 AM, Steven D'Aprano
wrote:
> In the Unix world, text formats and text
> processing is much more common in user-space apps than binary processing.
> Perhaps the definitive explanation and celebration of the Unix way is
> Eric Raymond's "The Art Of Unix Programming":
>
>
On Fri, Jun 6, 2014 at 1:37 AM, Robin Becker wrote:
> I think I'm in the unix camp as well. I just think that an extra assumption
> on input output isn't always helpful. In python 3 byte strings are second
> class which I think is wrong; apparently pressure from influential users is
> pushing to m
On 05/06/2014 15:45, Marko Rauhamaa wrote:
Rustom Mody :
What Marko is saying is that by imposing the structuring of unicode on
the outside (Unix) world of text=byte, significant power is lost.
Mostly I'm saying Python3 will not be able to hide the fact that linux
data consists of bytes. It s
On Thu, 05 Jun 2014 17:45:34 +0300, Marko Rauhamaa wrote:
> Rustom Mody :
>
>> What Marko is saying is that by imposing the structuring of unicode on
>> the outside (Unix) world of text=byte, significant power is lost.
>
> Mostly I'm saying Python3 will not be able to hide the fact that linux
>
Rustom Mody :
> What Marko is saying is that by imposing the structuring of unicode on
> the outside (Unix) world of text=byte, significant power is lost.
Mostly I'm saying Python3 will not be able to hide the fact that linux
data consists of bytes. It shouldn't even try. The linux OS outside the
On Thursday, June 5, 2014 3:11:34 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano wrote:
> > But the idea of having standard input and standard output in the first
> > place comes about because they are useful for the console.
> I doubt that. Classic programs take input and produce output. S
Chris Angelico :
> If the standard streams are so crucial, why are their most obvious
> interfaces insignificant to you?
I want the standard streams to consume and produce bytes. I do a lot of
system programming and connect processes to each other with socketpairs,
pipes and the like. I have deal
Steven D'Aprano :
> But the idea of having standard input and standard output in the first
> place comes about because they are useful for the console.
I doubt that. Classic programs take input and produce output. Standard
input and output are the default input and output. The textbook Pascal
pro
On Thu, Jun 5, 2014 at 6:05 PM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> If, in Python, I say print("Hello, world!"), I expect that to produce
>> a line of text on the screen, without my code having to encode that to
>> bytes, figure out what sort of newline to add, etc, etc.
>
> That example
On Thu, 05 Jun 2014 14:01:50 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> The whole concept of stdin and stdout is based on the idea of having a
>> console to read from and write to.
>
> Not really; stdin and stdout are frequently connected to files, or pipes
> to other processes. The
Chris Angelico :
> If, in Python, I say print("Hello, world!"), I expect that to produce
> a line of text on the screen, without my code having to encode that to
> bytes, figure out what sort of newline to add, etc, etc.
That example in no way represents the typical Python program (if there
is on
On Thu, Jun 5, 2014 at 5:16 PM, Marko Rauhamaa wrote:
> No problem there, only should sys.stdin and sys.stdout carry the
> decoding/encoding out or should it be left for the program.
The most normal thing to do with the standard streams is to have them
produce text, and as much as possible, you s
Gregory Ewing :
> As a result, most unix programs, most of the time, deal
> with text on stdin and stdout.
Well, ok. But even accepting that premise, that "text" might not be what
Python3 considers "text".
For example, if your program reads in XML, JSON or Python, the parser
object might prefer
Steven D'Aprano writes:
> On Tue, 03 Jun 2014 15:18:19 +0100, Robin Becker wrote:
>
>> Isn't it a bit old fashioned to think everything is connected to a
>> console?
>
> The whole concept of stdin and stdout is based on the idea of having a
> console to read from and write to. Otherwise, what wo
Steven D'Aprano wrote:
The whole concept of stdin and stdout is based on the idea of having a
console to read from and write to.
Not really; stdin and stdout are frequently connected to
files, or pipes to other processes. The console, if it
exists, just happens to be a convenient default value
On Tue, 03 Jun 2014 15:18:19 +0100, Robin Becker wrote:
>
>> The problem is that causal readers like Robin sometimes jump from 'In
>> Python 3, it can be hard to do something one really ought not to do' to
>> 'Binary I/O is hard in Python 3' -- which is is not.
>>
> I'm fairly causal and
On 6/3/2014 10:18 AM, Robin Becker wrote:
I think the idea that we only give meaning to binary data using
encodings is a bit limiting.
On the contrary, it is liberating. The fact that bits have no meaning
other than 'a choice between two alterntives' means
1. any binary choice - 0/1, -/+, fal
On Wed, Jun 4, 2014 at 2:34 AM, Steven D'Aprano
wrote:
> Outside of those three kinds of files, I would expect that *by far* the
> single largest kind of file is text. Some text is wrapped in a binary
> layer, e.g. .doc, .odt, etc. but an awful lot of it is good old human
> readable text, includin
On Mon, 02 Jun 2014 12:10:48 +0100, Robin Becker wrote:
> there seems to be an implicit assumption in python land that encoded
> strings are the norm. On virtually every computer I encounter that
> assumption is wrong. The vast majority of bytes in most computers is not
> something that can be eas
On Wed, Jun 4, 2014 at 12:18 AM, Robin Becker wrote:
> I think the idea that we only give meaning to binary data using encodings is
> a bit limiting. A zip or gif file has structure, but I don't think it's
> reasonable to regard such a file as having an encoding in the python unicode
> sense.
Of
The problem is that causal readers like Robin sometimes jump from 'In Python 3,
it can be hard to do something one really ought not to do' to 'Binary I/O is
hard in Python 3' -- which is is not.
I'm fairly causal and I did understand that the rant was a bit over the top for
fairly prac
On 6/3/2014 1:16 AM, Gregory Ewing wrote:
Terry Reedy wrote:
The issue Armin ran into is this. He write a library module that makes
sure the streams are binary.
Seems to me he made a mistake right there. A library should
*not* be making global changes like that. It can obtain
binary streams fr
Terry Reedy wrote:
The issue Armin ran into is this. He write a library module that makes
sure the streams are binary.
Seems to me he made a mistake right there. A library should
*not* be making global changes like that. It can obtain
binary streams from stdin and stdout for its own use, but
it
On 6/2/2014 7:10 AM, Robin Becker wrote:
there seems to be an implicit assumption in python land that encoded
strings are the norm.
I don't know why you say that. To have a stream of bytes interpreted as
characters, open in text mode and give the encoding. Otherwise, open in
binary mode and
I probably should have mentioned it, but in my case it's not even Python
(Java). It's exactly the same principal - an assumption was made that has
become entrenched due to the fear of breakage. If they'd been forced to
think about encodings up-front, it shouldn't have been an issue,
On Mon, Jun 2, 2014 at 7:02 PM, Tim Delaney wrote:
> In Java, it's much worse. At least with Python you can perform string-like
> operations on bytes. In Java you have to convert it to characters before you
> can really do anything with it, so people just use the default encoding all
> the time -
On 2 June 2014 17:45, Wolfgang Maier <
wolfgang.ma...@biologie.uni-freiburg.de> wrote:
> Tim Delaney gmail.com> writes:
>
> > For some purposes, there needs to be a way to treat an arbitrary stream
> of
> bytes as an arbitrary stream of 8-bit characters. iso-latin-1 is a
> convenient way to do th
Tim Delaney gmail.com> writes:
>
> I also should have been more clear that *in the particular situation I was
talking about* iso-latin-1 as default would be the right thing to do, not in
the general case. Quite often we won't know the correct encoding until we've
executed a command via ssh - iso
On Monday, June 2, 2014 7:53:05 AM UTC+5:30, Tim Delaney wrote:
> On 2 June 2014 11:14, Steven D'Aprano wrote:
>> Latin-1 is one of those legacy encodings which needs to die, not to be
>> entrenched as the default. My terminal uses UTF-8 by default (as it
>> should), and if I use the terminal to
On 2 June 2014 11:14, Steven D'Aprano
wrote:
> On Mon, 02 Jun 2014 08:54:33 +1000, Tim Delaney wrote:
> > I'm currently working on a product that interacts with lots of other
> > products. These other products can be using any encoding - but most of
> > the functions that interact with I/O assume
On Mon, 02 Jun 2014 08:54:33 +1000, Tim Delaney wrote:
> On 1 June 2014 12:26, Steven D'Aprano
> wrote:
>
>
>> "with cross-platform behavior preferred over system-dependent one" --
>> It's not clear how cross-platform behaviour has anything to do with the
>> Internet age. Python has preferred c
On 1 June 2014 12:26, Steven D'Aprano
wrote:
>
> "with cross-platform behavior preferred over system-dependent one" --
> It's not clear how cross-platform behaviour has anything to do with the
> Internet age. Python has preferred cross-platform behaviour forever,
> except for those features and m
On Sun, Jun 1, 2014 at 12:26 PM, Steven D'Aprano
wrote:
> TL;DR: Anatoly's blog post is long on disappointment and short on actual
> content. It feels to me that we could summarise his post as:
>
> I don't know what I want, I won't recognise it even if I saw
> it, but Python 3 isn't it. I
cript. I love Python, but really, more popular than
Javascript? That feels wrong to me.
In any case, I think that a better explanation for the observed dip in
Feb 2011 is not that Python 3.2 is infected (infected by what?) but
*regression to the mean*. Regression to the mean is a statistical
Mark Lawrence :
> Some interesting comments here
> http://techtonik.rainforce.org/2014/05/python-32-has-some-deadly-infection.html
> so I'm simply asking for other opinions.
I read the article, but unfortunately I failed to see interesting
comments or opinions. There was some graphic, but it didn
Some interesting comments here
http://techtonik.rainforce.org/2014/05/python-32-has-some-deadly-infection.html
so I'm simply asking for other opinions.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
---
This email is f
On 10/10/2013 2:49 PM, Isaac Gerg wrote:
Additionally, is there a place on the web to view this conversation and
reply? Currently, I am only able to access this list through email.
news.gmane.org newsgroup gmane.lang.python.general
Look at the headers for this message.
The site also has a sea
On Thu, 10 Oct 2013 18:16:07 -0500, mapoe wrote:
> On Thu, 10 Oct 2013 08:31:21 -0700, Isaac Gerg wrote:
>
>> I have a function that looks like the following:
>>
>> #-
>> filename = 'c:\testfile.h5'
>> f = open(filename,'r')
>> data = f.read()
>
> it seems kind o
On Thu, 10 Oct 2013 08:31:21 -0700, Isaac Gerg wrote:
> I have a function that looks like the following:
>
> #-
> filename = 'c:\testfile.h5'
> f = open(filename,'r')
> data = f.read()
it seems kind of obvious from your sample:
add: f.close()
> q = multiprocessin
Hi Piet,
Here is a real code example:
http://stackoverflow.com/questions/948119/preventing-file-handle-inheritance-in-multiprocessing-lib
As I said before, I had provide pseudocode.
I cannot close the file after reading because it is part of a class and other
threads may be calling member func
Isaac Gerg writes:
> Sorry, I am just providing pseudo code since I the code i have is quite large.
>
> As I mentioned, the code works fine when I remove the multirpcessing stuff so
> the filename is not the issue (though you are right in your correction).
>
> Someone with the same problem poste
27;
>>>>
>>>> --
>>>>
>>>> Piet van Oostrum
>>>>
>>>> WWW: http://pietvanoostrum.com/
>>>>
>>>> PGP key: [8DAE142BE17999C4]
>>>>
>>>
>>
> I will try what you suggest and see
On Thu, Oct 10, 2013 at 2:41 PM, Ned Batchelder wrote:
> On 10/10/13 12:44 PM, Isaac Gerg wrote:
>
>> Sorry, I am just providing pseudo code since I the code i have is quite
>> large.
>>
>> As I mentioned, the code works fine when I remove the multirpcessing
>> stuff so the filename is not the iss
1 - 100 of 403 matches
Mail list logo
