Sounds like a good compromise to me - and we certainly have a lot of
interesting experience to feed into the design of PEP 457 for 3.5 ;)
Cheers,
Nick.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
In the absence of a ruling from above I'm making a decision. I say we
keep the docstring hack, but go back to the human-readable version, only
this time with a *much* stricter signature. That should reduce the
number of false positives to zero.
Furthermore, I say we don't add any flags--ad
On 02/04/2014 05:24 AM, Antoine Pitrou wrote:
On Tue, 04 Feb 2014 05:08:28 -0800
Larry Hastings wrote:
On 02/04/2014 04:17 AM, Antoine Pitrou wrote:
As you see the signature string has vanished from the __doc__ contents.
This means that any tool directly processing __doc__ attributes to
genera
On 02/04/2014 05:19 AM, Victor Stinner wrote:
2014-02-04 Larry Hastings :
Why couldn't these tools use inspect.Signature?
inspect.Signature was added in Python 3.3. Python 2 is still widely
used, and some Linux distro only provide Python 3.2.
By the way, help(dict.fromkeys) looks to use __doc_
On 2/4/2014 9:03 AM, Lukas Vacek wrote:
Hi everyone,
Just wondering if anyone has looked into
http://bugs.python.org/issue19186 - priority has been changed to
critical four months ago but nothing has happened since.
I think it would be nice to get this sorted before python3.4 release
Benjamin
This is a mailing list for the development *of* Python, not *with* Python.
The best way to get help would be to email python-l...@python.org or
python-h...@python.org.
On Tue, Feb 4, 2014 at 10:15 AM, Milani Adelaide wrote:
> Dear support,
> we tried to install Phyton-3.3.3 but we got some prob
Am 04.02.2014 14:19, schrieb Victor Stinner:
> 2014-02-04 Larry Hastings :
>> Why couldn't these tools use inspect.Signature?
>
> inspect.Signature was added in Python 3.3. Python 2 is still widely
> used, and some Linux distro only provide Python 3.2.
Well, Python 2 won't be able to introspect C
Am 04.02.2014 13:14, schrieb Antoine Pitrou:
> On Tue, 04 Feb 2014 02:21:51 -0800
> Larry Hastings wrote:
>> On 02/04/2014 01:41 AM, Georg Brandl wrote:
>> > Clever, but due to the "hidden" space it also increases the frustration
>> > factor
>> > for people trying to find out "why is this accepte
Dear support,
we tried to install Phyton-3.3.3 but we got some problems with "make test".
Test whatever failed.
We trid also "make testall" but we got:
Ran 45 tests in 7.897s
FAILED (failures=25, skipped=15)
test test_gdb failed
make: *** [testall] Errore 1
Please could you help us?
Thanks
A
On 4 February 2014 02:04, 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 problem: h
Georg Brandl writes:
> I don't think a well-chosen visible separator is worse off, such as "--\n".
Don't you mean "-- \n"?
L'Ancien Mail-guique-ly y'rs,
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
Hi everyone,
Just wondering if anyone has looked into
http://bugs.python.org/issue19186- priority has been changed to
critical four months ago but nothing has
happened since.
I think it would be nice to get this sorted before python3.4 release
Cheers,
Lucas
__
On Tue, 04 Feb 2014 05:08:28 -0800
Larry Hastings wrote:
> On 02/04/2014 04:17 AM, Antoine Pitrou wrote:
> > As you see the signature string has vanished from the __doc__ contents.
> > This means that any tool directly processing __doc__ attributes to
> > generate (e.g.) automatic API docs will pr
2014-02-04 Larry Hastings :
> Why couldn't these tools use inspect.Signature?
inspect.Signature was added in Python 3.3. Python 2 is still widely
used, and some Linux distro only provide Python 3.2.
By the way, help(dict.fromkeys) looks to use __doc__, not the
signature, because the prototype is
On 02/04/2014 04:17 AM, Antoine Pitrou wrote:
As you see the signature string has vanished from the __doc__ contents.
This means that any tool directly processing __doc__ attributes to
generate (e.g.) automatic API docs will produce less useful docs.
Why couldn't these tools use inspect.Signatu
Hello,
Following the previous clinic thread, I realize that the latest
signature improvements actually entail a regression in __doc__.
Compare:
$ ./python -c "print(dict.fromkeys.__doc__)"
Returns a new dict with keys from iterable and values equal to value.
$ python3.3 -c "print(dict.fromkeys.
On Tue, 04 Feb 2014 02:21:51 -0800
Larry Hastings wrote:
> On 02/04/2014 01:41 AM, Georg Brandl wrote:
> > Clever, but due to the "hidden" space it also increases the frustration
> > factor
> > for people trying to find out "why is this accepted as a signature and not
> > this".
> >
> > I don't
On 02/03/2014 08:05 AM, Stefan Krah wrote:
I think we may slowly get into PEP territory here. Just imagine that
we settle on X, then decide at a later point to have a standard way of
adding type annotations, then find that X does not work because of (unknown).
I'm mentioning this because signat
On 02/04/2014 01:41 AM, Georg Brandl wrote:
Clever, but due to the "hidden" space it also increases the frustration factor
for people trying to find out "why is this accepted as a signature and not
this".
I don't think a well-chosen visible separator is worse off, such as "--\n".
I could live
On 02/03/2014 02:26 PM, Antoine Pitrou wrote:
How do you create an array that mixes PyMethodDefs and PyMethodDefExs
together?
You're right, you wouldn't be able to. For my PyMethodDefEx proposal,
the entire array would have to be one way or the other.
It sounds like METH_SIGNATURE is th
On 02/03/2014 02:06 PM, Gregory P. Smith wrote:
Wouldn't your proposal to extend the PyMethodDef structure would
require ifdef's and make it impossible to include the type information
in something compiled against the 3.3 headers that you want to use in
3.4 without recompiling?
It might use #
On 02/03/2014 01:10 PM, Zachary Ware wrote:
What about just choosing a marker value that is somewhat less
unsightly? "signature = (", or "parameters: (", or something (better)
to that effect? It may not be beautiful in 3.3, but we can at least
make it make sense.
It's a reasonable enough idea
On 02/03/2014 12:55 PM, Terry Reedy wrote:
I think the solution adopted should be future-oriented (ie, clean in
the future) even if the cost is slight awkwardness in 3.3.
Just a minor point: I keep saying 3.3, but I kind of mean "3.2 through
3.3". I believe the binary ABI shipped with 3.2.
Am 04.02.2014 10:12, schrieb Larry Hastings:
> If you won't let me have a flag, can I at least have a more-clever marker?
> How
> about this:
>
> (...)\n \n
>
> Yes, the last four characters are right-parenthesis, newline, space, and
> newline. Benefits:
>
> * The odds of finding *that
On 02/03/2014 08:19 PM, Guido van Rossum wrote:
But why do you even need a flag? Reading issue 20075 where the
complaint started, it really feels that the change was an overreaction
to a very minimal problem.
I'll cop to that. I'm pretty anxious about trying to "get it right".
My worry wa
25 matches
Mail list logo
