On Mon, May 20, 2013 at 1:51 AM, Gregory P. Smith wrote:
>
> On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote:
>>
>> 2013/5/19 Gregory P. Smith :
>> > Idea: I don't believe anybody has written a fixer for lib2to3 that
>> > applies
>> > fixers to doctests. That'd be an interesting project for s
On 05/19/2013 05:24 PM, Nick Coghlan wrote:
This is the point I was trying to make: once you use IntEnum (as you
would in any case where you need bitwise operators), Enum gets out of
the way for everything other than __str__, __repr__, and one other
slot (that escapes me for the moment...).
__
Gregory P. Smith writes:
> I really do applaud the goal of keeping examples in documentation up to
> date. But doctest as it is today is the wrong approach to that. A repr
> mismatch does not mean the example is out of date.
Of course it does. The user sees something in the doc that's
differ
On Mon, May 20, 2013 at 11:46 AM, Guido van Rossum wrote:
> On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith wrote:
>> Now you've got me wondering what Python would be like if repr, `` and
>> __repr__ never existed as language features. Upon first thoughts, I actually
>> don't see much downside
On Mon, May 20, 2013 at 11:19 AM, Demian Brecht wrote:
> @nick: Yes, I realize what docstrings are for (I should have used that
> term rather than "inline" docs, my bad there :)). I think the problem
> that I've run into is simply inconsistencies in methods of documenting
> code (and the few times
On 20/05/13 09:27, Gregory P. Smith wrote:
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
Bad: doctests.
I'm hoping that core developers don't get caught-up in the "doctests are
bad meme".
So
On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith wrote:
> Now you've got me wondering what Python would be like if repr, `` and
> __repr__ never existed as language features. Upon first thoughts, I actually
> don't see much downside (no, i'm not advocating making that change).
> Something to pond
Joao S. O. Bueno wrote:
Actually, when I was thinking on the subject I came to the same idea, of having
some functions marked differently so they would use a different call mechanism -
but them I wondered around having a different opcode for the ordered-dict calls.
Would that be feasible?
No,
@nick: Yes, I realize what docstrings are for (I should have used that
term rather than "inline" docs, my bad there :)). I think the problem
that I've run into is simply inconsistencies in methods of documenting
code (and the few times that it would have been helpful, what I was
looking at had not
[Raymond Hettinger]
> I'm hoping that core developers don't get caught-up in the "doctests are bad
> meme".
>
> Instead, we should be clear about their primary purpose which is to test
> the examples given in docstrings.
I disagree.
> In many cases, there is a great deal of benefit to docstrin
On Mon, May 20, 2013 at 10:14 AM, Antoine Pitrou wrote:
> On Sun, 19 May 2013 20:04:03 -0400
> Ned Batchelder wrote:
>> On 5/19/2013 7:22 PM, Mark Janssen wrote:
>> > On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote:
>> >> -BEGIN PGP SIGNED MESSAGE-
>> >> Hash: SHA1
>> >>
>> >> On 05/1
On Sun, 19 May 2013 20:04:03 -0400
Ned Batchelder wrote:
> On 5/19/2013 7:22 PM, Mark Janssen wrote:
> > On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> On 05/19/2013 10:48 AM, Guido van Rossum wrote:
> >>> Anyway, if you're do
On 5/19/2013 7:22 PM, Mark Janssen wrote:
On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2013 10:48 AM, Guido van Rossum wrote:
Anyway, if you're doing arithmetic on enums you're doing it wrong.
Hmm, bitwise operations, even?
I thi
On 20/05/2013 12:47am, Pierre Rouleau wrote:
Moreover, the development version is 3.4, and in Python 3 the int
type is a variable-length integer type (sys.maxint doesn't exist
anymore). So this discussion is largely moot now.
Good to know. Too bad there still are libraries not supp
On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote:
>
> 2013/5/19 Gregory P. Smith :
> > Idea: I don't believe anybody has written a fixer for lib2to3 that
applies
> > fixers to doctests. That'd be an interesting project for someone.
>
> 2to3 can operate on doctests, though it doesn't do anything
On 20 May 2013 08:51, "Demian Brecht" wrote:
>
> @benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless
> there's some custom build steps that I'm unaware of that may prevent
> it, it should still be relatively easy to maintain the desired
> narrative structure as long as the inline API
On Sun, May 19, 2013 at 7:41 PM, Antoine Pitrou wrote:
> On Sun, 19 May 2013 19:37:46 -0400
> Pierre Rouleau wrote:
>
> > On that topic of bitness for 64-bit platforms, would it not be better for
> > CPython to be written such that it uses the same 64-bit strategy on all
> > 64-bit platforms, re
On Sun, 19 May 2013 19:37:46 -0400
Pierre Rouleau wrote:
> On that topic of bitness for 64-bit platforms, would it not be better for
> CPython to be written such that it uses the same 64-bit strategy on all
> 64-bit platforms, regardless of the OS?
>
> As it is now, Python running on 64-bit Wind
On that topic of bitness for 64-bit platforms, would it not be better for
CPython to be written such that it uses the same 64-bit strategy on all
64-bit platforms, regardless of the OS?
As it is now, Python running on 64-bit Windows behaves differently (in
terms of bits for the Python's integer) t
2013/5/19 Gregory P. Smith :
> Idea: I don't believe anybody has written a fixer for lib2to3 that applies
> fixers to doctests. That'd be an interesting project for someone.
2to3 can operate on doctests, though it doesn't do anything different
to them than it does to normal sourcecode.
--
Regar
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
>
> Bad: doctests.
>
>
> I'm hoping that core developers don't get caught-up in the "doctests are
> bad meme".
>
So long as doctests insist on compar
OK thanks, Benjamin,
you are correct sys.maxsize is 2*63-1 on it.
I was under the impression that Python was using int_64_t for the
implementation of Win64 based integers. Most probably because I've sen
discussion on Python 64 bits and those post were most probably were in the
scope of some Unix
On Sun, May 19, 2013 at 1:13 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/19/2013 10:48 AM, Guido van Rossum wrote:
>> Anyway, if you're doing arithmetic on enums you're doing it wrong.
>
> Hmm, bitwise operations, even?
I think it's rather pointless to do bi
2013/5/19 Pierre Rouleau :
> Hi all,
>
> I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer.
> When I evaluate sys.maxint I don't get what I was expected. I get this:
>
> Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)] on
> win32
> Type "copyright",
Hi all,
I just installed Python 2.7.5 64-bit () on a Windows 7 64-bit OS computer.
When I evaluate sys.maxint I don't get what I was expected. I get this:
Python 2.7.5 (default, May 15 2013, 22:44:16) [MSC v.1500 64 bit (AMD64)]
on win32
Type "copyright", "credits" or "license()" for more infor
@benjamin: Ah, i see. I wasn't around pre-Sphinx. However, unless
there's some custom build steps that I'm unaware of that may prevent
it, it should still be relatively easy to maintain the desired
narrative structure as long as the inline API docs are kept terse.
@antoine: Sorry, I may not have b
On 20 May 2013 06:25, "Terry Jan Reedy" wrote:
>
> On 5/19/2013 4:13 PM, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 05/19/2013 10:48 AM, Guido van Rossum wrote:
>>>
>>> Anyway, if you're doing arithmetic on enums you're doing it wrong.
>>
>>
>> Hmm, bitwise
On 20 May 2013 00:57, "Guido van Rossum" wrote:
>
> Hm. Wouldn'tvevery call site be slowed down by checking for that flag?
Yeah, I forgot about having to push everything through the tp_call slot, so
we can't easily limit the ordering check to just those cases where the
callable accepts arbitrary
2013/5/19 Demian Brecht :
> This is more out of curiosity than to spark change (although I
> wouldn't argue against it): Does anyone know why it was decided to
> document external to source files rather than inline?
>
> When rapidly digging through source, it would be much more helpful to
> see par
On Sun, 19 May 2013 15:29:37 -0700
Demian Brecht wrote:
> This is more out of curiosity than to spark change (although I
> wouldn't argue against it): Does anyone know why it was decided to
> document external to source files rather than inline?
>
> When rapidly digging through source, it would b
This is more out of curiosity than to spark change (although I
wouldn't argue against it): Does anyone know why it was decided to
document external to source files rather than inline?
When rapidly digging through source, it would be much more helpful to
see parameter docs than to either have to fi
On 5/19/2013 4:13 PM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2013 10:48 AM, Guido van Rossum wrote:
Anyway, if you're doing arithmetic on enums you're doing it wrong.
Hmm, bitwise operations, even?
Those are logic, not arithmetic as usually understood. (Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2013 12:14 PM, Dan Stromberg wrote:
> On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
> raymond.hettin...@gmail.com> wrote:
>
>>
>> On May 14, 2013, at 9:39 AM, Gregory P. Smith
>> wrote:
>>
>> Bad: doctests.
>>
>>
>> I'm hoping t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/19/2013 10:48 AM, Guido van Rossum wrote:
> Anyway, if you're doing arithmetic on enums you're doing it wrong.
Hmm, bitwise operations, even?
Tres.
- --
===
Tres Seaver
On 19/05/2013 5:03pm, Benjamin Peterson wrote:
> Shouldn't this go to the python-tulip list?
Yes. Sorry about that.
--
Richard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote:
>
> Bad: doctests.
>
>
> I'm hoping that core developers don't get caught-up in the "doctests are
> bad meme".
>
Don't doctests intended for CPython
Shouldn't this go to the python-tulip list?
2013/5/19 Richard Oudkerk :
> Attached is a pretty trivial example of asynchronous interaction with a
> python subprocess using tulip on Windows. It does not use transports or
> protocols -- instead sock_recv() and sock_sendall() are used inside tasks.
Attached is a pretty trivial example of asynchronous interaction with a
python subprocess using tulip on Windows. It does not use transports or
protocols -- instead sock_recv() and sock_sendall() are used inside tasks.
I am not sure what the plan is for dealing with subprocesses currently.
S
Anyway, if you're doing arithmetic on enums you're doing it wrong.
—
Sent from Mailbox
On Sun, May 19, 2013 at 4:55 AM, Nick Coghlan wrote:
> On Sun, May 19, 2013 at 4:41 PM, Raymond Hettinger
> wrote:
>> nicer repr" is worth "Sorry, I broke your tests, made your published
>> examples
>> out o
On Mon, 20 May 2013 01:09:19 +1000
Nick Coghlan wrote:
> On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou wrote:
> > On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> > "Guido van Rossum" wrote:
> >> Fake values would probably cause hard to debug problems. It's a long
> >> standing Python tradition no
On 19 May 2013 11:57, Guido van Rossum wrote:
> Hm. Wouldn'tvevery call site be slowed down by checking for that flag?
Actually, when I was thinking on the subject I came to the same idea, of having
some functions marked differently so they would use a different call mechanism -
but them I wonder
On Mon, May 20, 2013 at 12:51 AM, Antoine Pitrou wrote:
> On Sun, 19 May 2013 07:47:14 -0700 (PDT)
> "Guido van Rossum" wrote:
>> Fake values would probably cause hard to debug problems. It's a long
>> standing Python tradition not to offer low level APIs that the platform
>> doesn't have.
>
>
On Sun, May 19, 2013 at 4:40 PM, Nick Coghlan wrote:
> On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:
>> The main use case seems to be the OrderedDict constructor itself.
>> Otherwise, I can't think of any situation where I would've wanted it.
>
> I've had a couple related to populating
Hm. Wouldn'tvevery call site be slowed down by checking for that flag?
—
Sent from Mailbox
On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan wrote:
> On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:
>> The main use case seems to be the OrderedDict constructor itself.
>> Otherwise, I can't th
On Sun, 19 May 2013 07:47:14 -0700 (PDT)
"Guido van Rossum" wrote:
> Fake values would probably cause hard to debug problems. It's a long standing
> Python tradition not to offer low level APIs that the platform doesn't have.
I meant the platform, not Python.
Regards
Antoine.
> —
> Sent from
Fake values would probably cause hard to debug problems. It's a long standing
Python tradition not to offer low level APIs that the platform doesn't have.
—
Sent from Mailbox
On Sun, May 19, 2013 at 5:20 AM, Antoine Pitrou
wrote:
> On Sun, 19 May 2013 10:08:39 +0200
> Charles-François Natali w
On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:
> The main use case seems to be the OrderedDict constructor itself.
> Otherwise, I can't think of any situation where I would've wanted it.
I've had a couple related to populating other mappings where order
matters, at least from a predictab
On Sun, May 19, 2013 at 7:27 AM, Raymond Hettinger
wrote:
>
> On May 15, 2013, at 4:32 AM, Christian Tismer wrote:
>
> What is the current status of this discussion?
> I'd like to know whether it is a considered alternative implementation.
>
>
> As far as I can tell, I'm the only one working on i
On Sat, 18 May 2013 22:47:35 -0700
Guido van Rossum wrote:
> On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger
> wrote:
> > BTW, I'm +1 on the idea for ordering keyword-args. It makes
> > it easier to debug if the arguments show-up in the order they
> > were created. AFAICT, no purpose is ser
> On Sat, May 18, 2013 at 10:27 PM, Raymond Hettinger
> wrote:
>> BTW, I'm +1 on the idea for ordering keyword-args. It makes
>> it easier to debug if the arguments show-up in the order they
>> were created. AFAICT, no purpose is served by scrambling them
>> (which is exacerbated by the new rand
On Sun, 19 May 2013 10:08:39 +0200
Charles-François Natali wrote:
> 2013/5/17 Antoine Pitrou :
> >
> > Hello,
> >
> > Some pieces of code are still guarded by:
> > #ifdef HAVE_FSTAT
> > ...
> > #endif
> >
> > I would expect all systems to have fstat() these days. It's pretty
> > basic POSIX, and
On Sun, May 19, 2013 at 4:41 PM, Raymond Hettinger
wrote:
> nicer repr" is worth "Sorry, I broke your tests, made your published
> examples
> out of date, and slowed down your code."
While the first two considerations are always potentially applicable
when using enums, the latter should only be t
2013/5/17 Antoine Pitrou :
>
> Hello,
>
> Some pieces of code are still guarded by:
> #ifdef HAVE_FSTAT
> ...
> #endif
>
> I would expect all systems to have fstat() these days. It's pretty
> basic POSIX, and even Windows has had it for ages. Shouldn't we simply
> make those code blocks unconditi
53 matches
Mail list logo
