On Mon, 23 Jan 2017 02:19 am, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Sun, 22 Jan 2017 07:34 pm, Marko Rauhamaa wrote:
>>
>>> Steve D'Aprano :
>>>
On Sun, 22 Jan 2017 06:52 am, Marko Rauhamaa wrote:
> Also, [surrogates] don't exist as Unicode code points. Python
> shouldn't
On 01/22/2017 07:02 PM, MRAB wrote:
On 2017-01-23 00:10, Jim wrote:
Does anyone know if the changes outlined here [1] have been implemented?
Supposedly changes have been made to pyuno to make it more pythonic.
Item 2 Cellranges says that:
cell = sheet.getCellByPosition(cellCol + col, cellRow +
On 2017-01-22, Christian Heimes wrote:
> On 2017-01-22 21:18, Grant Edwards wrote:
>> Is the Python SSL API thread-safe with respect to recv() and send()?
>>
>> IOW, can I have one thread doing blocking recv() calls on an SSL
>> connection object while "simultaneously" a second thread is calling
On 2017-01-23 00:10, Jim wrote:
Does anyone know if the changes outlined here [1] have been implemented?
Supposedly changes have been made to pyuno to make it more pythonic.
Item 2 Cellranges says that:
cell = sheet.getCellByPosition(cellCol + col, cellRow + row)
Can be written as:
cell = sheet
Does anyone know if the changes outlined here [1] have been implemented?
Supposedly changes have been made to pyuno to make it more pythonic.
Item 2 Cellranges says that:
cell = sheet.getCellByPosition(cellCol + col, cellRow + row)
Can be written as:
cell = sheet.cellrange[cellRow + row, cellCol
On 2017-01-22 21:18, Grant Edwards wrote:
> Is the Python SSL API thread-safe with respect to recv() and send()?
>
> IOW, can I have one thread doing blocking recv() calls on an SSL
> connection object while "simultaneously" a second thread is calling
> send() on that same connection object?
>
>
On 2017-01-22, Grant Edwards wrote:
> Is the Python SSL API thread-safe with respect to recv() and send()?
>
> IOW, can I have one thread doing blocking recv() calls on an SSL
> connection object while "simultaneously" a second thread is calling
> send() on that same connection object?
I think th
Is the Python SSL API thread-safe with respect to recv() and send()?
IOW, can I have one thread doing blocking recv() calls on an SSL
connection object while "simultaneously" a second thread is calling
send() on that same connection object?
I assumed that was allowed, but I can't find anything in
Steve D'Aprano :
> On Sun, 22 Jan 2017 07:34 pm, Marko Rauhamaa wrote:
>
>> Steve D'Aprano :
>>
>>> On Sun, 22 Jan 2017 06:52 am, Marko Rauhamaa wrote:
Also, [surrogates] don't exist as Unicode code points. Python
shouldn't allow surrogate characters in strings.
>>>
>>> Not quite. This
On Sun, 22 Jan 2017 07:34 pm, Marko Rauhamaa wrote:
> Steve D'Aprano :
>
>> On Sun, 22 Jan 2017 06:52 am, Marko Rauhamaa wrote:
>>> Also, [surrogates] don't exist as Unicode code points. Python
>>> shouldn't allow surrogate characters in strings.
>>
>> Not quite. This is where it gets a bit messy
On 2017-01-22 01:03, Grant Edwards wrote:
> On 2017-01-21, Christian Heimes wrote:
>
>> You might be interested in my small module
>> https://pypi.python.org/pypi/socketfromfd/ . I just releases a new
>> version with a fix for Python 2. Thanks for the hint! :)
>>
>> The module correctly detects a
Steve D'Aprano :
> On Sun, 22 Jan 2017 06:52 am, Marko Rauhamaa wrote:
>> Also, [surrogates] don't exist as Unicode code points. Python
>> shouldn't allow surrogate characters in strings.
>
> Not quite. This is where it gets a bit messy and confusing. The bottom
> line is: surrogates *are* code po
eryk sun :
> On Sat, Jan 21, 2017 at 8:21 PM, Pete Forman wrote:
>> Marko Rauhamaa writes:
>>
py> low = '\uDC37'
>>>
>>> That should raise a SyntaxError exception.
>>
>> Quite. [...]
>
> CPython allows surrogate codes for use with the "surrogateescape" and
> "surrogatepass" error handlers,
13 matches
Mail list logo
