Larry Hastings writes:
> In the second attempt, the signature looked like this:
>
>sig=(arguments)\n
>
[...]
> This all has caused no problems so far. But my panicky email last
> night was me realizing a problem we may see down the road. To recap:
> if a programmer writes a module using the
Hmm... I liked the original scheme because it doesn't come out so badly if
some tool doesn't special-case the first line of the docstring at all. (I
have to fess up that I wrote such a tool for a limited case not too long
ago, and I wrote it to search for a blank line if the docstring starts with
On 02/03/2014 09:46 AM, Guido van Rossum wrote:
Can you summarize why neither of the two schemes you tried so far worked?
Certainly.
In the first attempt, the signature looked like this:
(arguments)\n
The "(arguments)" part of the string was 100% compatible with Python
syntax. So much
On Mon, 03 Feb 2014 06:43:31 -0800
Larry Hastings wrote:
>
> A: We create a PyMethodDefEx structure with an extra field: "const char
> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
> the flags, indicating that this is an extended structure. When
> iterating over the
On Mon, Feb 3, 2014 at 8:04 AM, Larry Hastings wrote:
> On 02/03/2014 07:08 AM, Barry Warsaw wrote:
>
> On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote:
>
>
> But that only fixes part of the problem. Our theoretical extension that
> wants to be binary-compatible with 3.3 and 3.4 still has a
On Mon, Feb 3, 2014 at 8:43 AM, Larry Hastings wrote:
>
>
> A quick summary of the context: currently in CPython 3.4, a builtin function
> can publish its "signature" as a specially encoded line at the top of its
> docstring. CPython internally detects this line inside
> PyCFunctionObject.__doc__
On 2/3/2014 9:43 AM, Larry Hastings wrote:
A quick summary of the context: currently in CPython 3.4, a builtin
function can publish its "signature" as a specially encoded line at the
top of its docstring. CPython internally detects this line inside
PyCFunctionObject.__doc__ and skips past it,
Hi Victor,
You can find instructions here to produce a patch:
http://docs.python.org/devguide/
The first thing to do would be to create an issue on
http://bugs.python.org/, and post your patch there.
Regards
Antoine.
On Mon, 3 Feb 2014 23:41:22 +0400
Виктор Щерба wrote:
> Hi, guys!
>
> I h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/03/2014 02:41 PM, ?? ? wrote:
> Hi, guys!
>
> I have found a bug in module "time" function "sleep" in Python 2.7
> under Windows XP / Server 2003 and lower. I fix this bug locally. But
> how could I send you hg patch or pull request or,
Hi Victor,
On Mon, Feb 3, 2014 at 1:41 PM, Виктор Щерба wrote:
> Hi, guys!
>
> I have found a bug in module "time" function "sleep" in Python 2.7 under
> Windows XP / Server 2003 and lower.
> I fix this bug locally. But how could I send you hg patch or pull request
> or, maybe, commit to sandbox?
2014-02-03 Benjamin Peterson :
>> The documentation is still outdated. For example, I don't see the new
>> subprocess page in
>> http://docs.python.org/dev/library/asyncio.html
>
> Finally fixed.
Thanks.
Victor
___
Python-Dev mailing list
Python-Dev@pyt
On Mon, Feb 3, 2014 at 2:41 PM, Виктор Щерба wrote:
> Hi, guys!
>
> I have found a bug in module "time" function "sleep" in Python 2.7 under
> Windows XP / Server 2003 and lower.
> I fix this bug locally. But how could I send you hg patch or pull request
> or, maybe, commit to sandbox?
>
Please
On 03/02/2014 19:41, Виктор Щерба wrote:
Hi, guys!
I have found a bug in module "time" function "sleep" in Python 2.7 under
Windows XP / Server 2003 and lower.
I fix this bug locally. But how could I send you hg patch or pull
request or, maybe, commit to sandbox?
The best thing is to raise an
Hi, guys!
I have found a bug in module "time" function "sleep" in Python 2.7 under
Windows XP / Server 2003 and lower.
I fix this bug locally. But how could I send you hg patch or pull request
or, maybe, commit to sandbox?
P.S.: Sorry for my English :-)
Best Regards,
Victor Scherba,
C++ develope
On Mon, Feb 3, 2014, at 08:36 AM, Victor Stinner wrote:
> 2014-02-03 Benjamin Peterson :
> >> Is it a problem with the server generating the documentation?
> >
> > Hopefully fixed now.
>
> The documentation is still outdated. For example, I don't see the new
> subprocess page in
> http://docs.py
On 02/03/2014 09:52 AM, Guido van Rossum wrote:
Can we provide a convenience API (or even a few lines of code one could
copy+paste) that determines if a particular
8-bit string should have max-char equal to 127 or 255?
Isn't that what this is?
On 03-02-2014 5:52 pm, Guido van Rossum wrote:
Can we provide a convenience API (or even a few lines of code one
could copy+paste) that determines if a particular 8-bit string
should have max-char equal to 127 or 255? I can easily imagine a
number of use cases where this would come in handy (e.g
On 02/03/2014 09:16 AM, Phil Thompson wrote:
So there *is* code that will fail if a particular Latin-1 string just
happens not to contains any character greater than 127?
Yes, because if it does not contain a character > 127 it is not a latin-1
string as far as Python is concerned.
--
~Etha
Can we provide a convenience API (or even a few lines of code one could
copy+paste) that determines if a particular 8-bit string should have
max-char equal to 127 or 255? I can easily imagine a number of use cases
where this would come in handy (e.g. a list of strings produced by
translation, or s
Larry,
Can you summarize why neither of the two schemes you tried so far worked?
AFAIR the original scheme was to support the 3.3-compatible syntax; there
was some kind of corner-case problem with this, so you switched to the new
"sig=..." syntax, but obviously this has poor compatibility with 3.3
On Mon, 03 Feb 2014 16:10:03 +
Phil Thompson wrote:
>
> Why is a Latin-1 string considered inconsistent just because it doesn't
> happen to contain any characters in the range 128-255?
Because as Victor said, it allows for some optimization shortcuts (e.g.
a non-ASCII latin1 string cannot b
On 03-02-2014 4:38 pm, Paul Moore wrote:
On 3 February 2014 16:10, Phil Thompson
wrote:
That doesn't answer my original question, that just works around the
use
case I presented.
To restate...
Why is a Latin-1 string considered inconsistent just because it
doesn't
happen to contain any cha
On Sat, Feb 1, 2014 at 9:14 PM, Nick Coghlan wrote:
> On 2 February 2014 11:06, Steven D'Aprano wrote:
> > Hi all,
> >
> > Over on the Python-ideas list, there's a thread about the new statistics
> > module, and as the author of that module, I'm looking for a bit of
> > guidance regarding backwa
On 3 February 2014 16:10, Phil Thompson wrote:
> That doesn't answer my original question, that just works around the use
> case I presented.
>
> To restate...
>
> Why is a Latin-1 string considered inconsistent just because it doesn't
> happen to contain any characters in the range 128-255?
Butt
2014-02-03 Benjamin Peterson :
>> Is it a problem with the server generating the documentation?
>
> Hopefully fixed now.
The documentation is still outdated. For example, I don't see the new
subprocess page in
http://docs.python.org/dev/library/asyncio.html
> It was twice a day before, I've now s
Larry Hastings wrote:
> So here's the problem. Let's say you want to write an extension that will
> work
> with Python 3.3 and 3.4, using the stable ABI. If you don't add this line,
> then in 3.4 you won't have introspection information, drat. But if you *do*
> add this line, your docstring wi
On 02/03/2014 07:08 AM, Barry Warsaw wrote:
On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote:
But that only fixes part of the problem. Our theoretical extension that
wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can
they support signatures? They can't give PyMethod
On 03-02-2014 4:04 pm, Victor Stinner wrote:
2014-02-03 Phil Thompson :
Are you saying that code will fail if a particular Latin-1 string
just
happens not to contains any character greater than 127?
PyUnicode_FromKindAndData(PyUnicode_1BYTE_KIND, latin1_str, length)
accepts latin1 and ASCII s
2014-02-03 Phil Thompson :
> Are you saying that code will fail if a particular Latin-1 string just
> happens not to contains any character greater than 127?
PyUnicode_FromKindAndData(PyUnicode_1BYTE_KIND, latin1_str, length)
accepts latin1 and ASCII strings. It computes the maximum code point
and
On 03-02-2014 3:35 pm, Victor Stinner wrote:
2014-02-03 Phil Thompson :
For example, a string created with a maxchar of 255 (ie. a Latin-1
string)
must contain at least one character in the range 128-255 otherwise
you get
an assertion failure.
Yes, it's the specification of the PEP 393.
As
2014-02-03 Phil Thompson :
> For example, a string created with a maxchar of 255 (ie. a Latin-1 string)
> must contain at least one character in the range 128-255 otherwise you get
> an assertion failure.
Yes, it's the specification of the PEP 393.
> As it stands, when converting Latin-1 strings
_PyUnicode_CheckConsistency() checks that the contents of the string
matches the _KIND of the string. However it does this in a very strict
manner, ie. that the contents *exactly* match the _KIND rather than just
detecting an inconsistency between the contents and the _KIND.
For example, a str
On Mon, Feb 3, 2014, at 02:22 AM, Victor Stinner wrote:
> Hi,
>
> I modified the Python documentaton (asyncio module) 6 days ago, and my
> changes are not online yet:
> http://docs.python.org/dev/library/asyncio-eventloop.html#running-subprocesses
>
> Is it a problem with the server generating th
On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote:
>But that only fixes part of the problem. Our theoretical extension that
>wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can
>they support signatures? They can't give PyMethodDefEx structures to 3.3, it
>will blow up.
A quick summary of the context: currently in CPython 3.4, a builtin
function can publish its "signature" as a specially encoded line at the
top of its docstring. CPython internally detects this line inside
PyCFunctionObject.__doc__ and skips past it, and there's a new getter at
PyCFunctionO
Hi,
I modified the Python documentaton (asyncio module) 6 days ago, and my
changes are not online yet:
http://docs.python.org/dev/library/asyncio-eventloop.html#running-subprocesses
Is it a problem with the server generating the documentation?
By the way, would it be possible to regenerate the d
36 matches
Mail list logo
