have a pointer to that memory area in order to do the matching
in the first place (although I realize the code may be separated by a
gulf of abstraction :-).
--Guido
On Mon, Jul 15, 2013 at 8:03 PM, Nick Coghlan wrote:
> On 16 July 2013 12:20, Guido van Rossum wrote:
>> On Mon,
shared between C and Python code for efficiency, and
being able to do pretty much anything to the buffer that you can do to
a bytes object (apart from using it as a dict key) helps a lot.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev ma
I have to say that a long time ago, when you couldn't tell a relative
import from a top-level import, the ban on relative imports made more
sense.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
to
the PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
and
> therefore we should talk about octets, will be slapped with a large halibut
> :-)
>
>
> --
> Steven
>
>
>
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailm
On Thu, Jul 18, 2013 at 6:15 AM, Ezio Melotti wrote:
> I don't think we need to introduce new terms.
+1
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/py
3 at 10:38 AM, Serhiy Storchaka wrote:
> What type of dash is preferable in the documentation? The en dash (–) or the
> em dash (—)?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/
On Thu, Jul 18, 2013 at 11:46 AM, Serhiy Storchaka wrote:
> 18.07.13 20:48, Guido van Rossum написав(ла):
>
>> I believe there are only a few places where en-dashes should be used,
>> for most things you should use either em-dash or hyphen. Consult your
>> trusted t
On Thu, Jul 18, 2013 at 12:16 PM, Richard Oudkerk wrote:
> On 18/07/2013 7:55pm, Guido van Rossum wrote:
>>
>> This may well be a relic from times when in typewritten text there
>> were really only two types of dashes: a short one, typed as a hyphen,
>> used for both hy
ypeError: unhashable type: 'set'
>>
>> It would be strange if the last test would return False instead of raising
>> an error.
>
>
> Yeah, that would be unfortunate.
>
> Okay, I can see dict.__contains__ and friends raising a TypeError, but what
> about dic
daemon creation code in the stdlib -- I wrote some damn
robust code for this purpose in my previous job, but it never saw the
light of day.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/m
ed easily. (If it even uses that -- I haven't
read the source code, maybe it uses named pipes? :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Jul 24, 2013 at 2:57 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 10:56:05 -0700
> Guido van Rossum wrote:
>>
>> But I'm also ready to propose that all this is such a mess that we
>> *should* change the default fd/handle inheritance to False, *acros
On Wed, Jul 24, 2013 at 3:35 PM, Antoine Pitrou wrote:
> On Wed, 24 Jul 2013 15:25:50 -0700
> Guido van Rossum wrote:
>> >> To reduce the need for 3rd party subprocess creation code, we should
>> >> have better daemon creation code in the stdlib -- I wrote some d
lthough we should probably avoid the second fcntl()
call if the first call shows the flag is already set the way we want
it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
D);
>> > fcntl(fd, F_SETFD, flags | FD_CLOEXEC)
>> > => 3% slower than open(path, O_RDONLY)
>>
>> Ok, so I think this it is a totally reasonable compromise.
>>
>> People who bother about a 3% slowdown when calling os.open() can
>> optimize the h
On Saturday, July 27, 2013, Victor Stinner wrote:
> 2013/7/27 Guido van Rossum >:
> > Do we even need a new PEP, or should we just do it? Or can we adapt
> > Victor's PEP 446?
>
> I can rewrite the PEP 446 to:
>
> * make all file descriptors and handles non
P.S. perhaps more important than a PEP rewrite is a working patch to see
how realistic this is. Could you make the alpha 1 release?
On Saturday, July 27, 2013, Guido van Rossum wrote:
>
>
> On Saturday, July 27, 2013, Victor Stinner wrote:
>
>> 2013/7/27 Guido van Rossum :
>
database and find
out which users use MyOpenID and email them individually?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
modules.
> (and then, we don't need to cache global functions for use in
> finalizers, either)
>
> I have a patch to suppress the hack in
> http://bugs.python.org/issue18214
> Once I get to add some tests, I would like to commit it so
ython.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
inheritable)
> else:
> os.set_inheritable(self.fileno(), inheritable)
>
> Usage: s.get_inheritable() and sock.set_inheritable(True)
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python
ng as the PEP makes it clear that this breaks backward
> compatibility, that's fine. IMO the risk of breakage outweights the
> modicum benefit.
I know this will break code. But it is for the good of mankind.
(I will now review the full PEP, finally.)
--
--Guido van Rossum (python
place to explain the rationale for this exception.
https://codereview.appspot.com/13240043/diff/3001/pep-0446.txt#newcode538
pep-0446.txt:538: descriptors).
I would say it should not be changed because the default is still better. :-)
--
--Guido van Rossum (python.org/~guido)
_
Wow, that was quick! I propose that we wait for one more day for any
feedback from others in response to this post, and then accept the PEP.
On Mon, Aug 26, 2013 at 3:19 PM, Victor Stinner wrote:
> 2013/8/26 Guido van Rossum :
> > I have reviewed the PEP and I think it is good. Tha
n into the next 3.4 alpha.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Whoop. Yes. I guess it was me who was tired. :-)
On Tuesday, August 27, 2013, Paul Moore wrote:
> On 27 August 2013 23:17, Guido van Rossum 'cvml', 'gu...@python.org');>
> > wrote:
>
>> Thanks for your tiresome work
>
>
> I'm guessing you
ther :-))
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev
Fa5PnfZe00Aay5l1rWzgj8d
> CY0D3W+PAdPkBci9SYPmfv7ajXrQWo/ccANYIRaUdI/U9Zjq/od7eNemOFqyL7U6
> BrQpAUMySI6tMlL+gYEfQ8O47SManvTqoyNvOFAz9mVJute8IxKsbCIK/jiRHDXz
> vWyG7YrYN1A=
> =4E7+
> -END PGP SIGNATURE-
> _______
> Python-Dev mailing
h it.
>
> So I'm -1, but that's a personal opinion :-)
>
> cf
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailm
___
>
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org
______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
is ready -- it looks very close already.
On Sun, Sep 8, 2013 at 10:32 AM, Guido van Rossum wrote:
> Going over the open issues:
>
> - Parallel arrays or arrays of tuples? I think the API should require
> an array of tuples. It is trivial to zip up parallel arrays to the
> require
Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are long.
On Sun, Sep 8, 2013 at 10:45 AM, Alexander Belopolsky
wrote:
>
> On Sun, Sep 8, 2013 at 9:32 PM, Guido van Rossum wrote:
>>
>> - Parallel arrays or arrays of tuples? I think the API should
On Sun, Sep 8, 2013 at 1:48 PM, Oscar Benjamin
wrote:
> On 8 September 2013 18:32, Guido van Rossum wrote:
>> Going over the open issues:
>>
>> - Parallel arrays or arrays of tuples? I think the API should require
>> an array of tuples. It is trivial to zip up paralle
ers of the new
statistics module will be more familiar with OO programming (e.g. the
Python DB API , PEP 249) than they are with other statistics packages.
On Sun, Sep 8, 2013 at 7:57 PM, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
> > On Sun, Sep 8, 2013 at 1:48 PM, Oscar
On Sun, Sep 8, 2013 at 5:26 PM, Greg wrote:
> On 9/09/2013 5:52 a.m., Guido van Rossum wrote:
>
>> Well, to me zip(*x) is unnatural, and it's inefficient when the arrays
>> are long.
>>
>
> Would it be worth having a transpose() function in the stdlib
> som
t
> Python-Dev@python.org
> https://mail.python.org/**mailman/listinfo/python-dev<https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org<https://mail.py
OK, how much time do you need?
--Guido van Rossum (sent from Android phone)
On Sep 9, 2013 8:44 AM, "Mark Shannon" wrote:
> I would like time to investigate this further, but at the moment I think
> it will either make attribute lookup poorly defined or slow.
>
> Of t
to add IOCP module for Windows ?
>
> Regards!
> peipei
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-d
f the system actually
> works. Hey, the video demos looked great...
>
> Glenn
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.
>
Thanks, Antoine!
Raymond Hettinger has volunteered to be the PEP dictator (is that the word
we use?) for this PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
I hope there is a volunteer for delegate.
--Guido van Rossum (sent from Android phone)
On Sep 16, 2013 1:17 AM, "Antoine Pitrou" wrote:
> Le Sun, 15 Sep 2013 06:46:08 -0700,
> Ethan Furman a écrit :
> > I see PEP 428 is both targeted at 3.4 and still in draft status.
>
t I believe the code
review is going well, so I'm not concerned that the PEP would have to
revised based on that alone.
On Fri, Sep 13, 2013 at 5:59 PM, Steven D'Aprano wrote:
> On Sun, Sep 08, 2013 at 10:51:57AM -0700, Guido van Rossum wrote:
> > Never mind, I found the patch
On Mon, Sep 16, 2013 at 4:59 PM, Steven D'Aprano wrote:
> On Mon, Sep 16, 2013 at 08:42:12AM -0700, Guido van Rossum wrote:
> > I'm ready to accept this PEP. Because I haven't read this entire thread
> > (and 60 messages about random diversions is really too much to
bes a graph). I propose that we truncate the table and add a note
saying that all following releases are owned by the PSF, GPL-compatible,
and derived from previous PSF-owned and GPL-compatible releases. That
should do until the PSF goes out of business (which I hope will never
happen -- this is one reaso
On Tue, Sep 17, 2013 at 10:39 AM, Antoine Pitrou wrote:
> On Tue, 17 Sep 2013 09:47:48 -0700
> Guido van Rossum wrote:
> >
> > IIRC this table was added when a few core Python developers including
> > myself left CNRI in 2000. We had a bit of an argument about the l
2013 at 5:06 PM, Guido van Rossum wrote:
> On Mon, Sep 16, 2013 at 4:59 PM, Steven D'Aprano wrote:
>
>> On Mon, Sep 16, 2013 at 08:42:12AM -0700, Guido van Rossum wrote:
>> > I'm ready to accept this PEP. Because I haven't read this entire thread
>> > (a
ble) and
> just saying "2.2 onwards" (or whatever is the best way to say it).
>
> cheers,
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> U
t; Which is why the message should be printed, so the developer can decide.
>
> --
> Terry Jan Reedy
>
>
> __**_____
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/**mailman/listinfo/python-dev<http
cise
(but not cryptic(*)), longer documentation go into the separately written
text for docs.python.org.
(*) This is too concise to my taste:
$ ls -?
ls: illegal option -- ?
usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1] [file ...]
$
--
--Guido van Rossum (python.org/~guido)
__
someone like me who
> hardly uses the html docs.
>
You seem to misunderstand the use of "autogeneration". It refers to
generating the .rst docs from the docstrings in the source. And FWIW, I'm
against that practice.
--
--Guido van Rossum (python.org/~guido)
_
tion most likely adds an extra barrier towards improving the
docs.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mai
On Sun, Sep 22, 2013 at 10:35 AM, Terry Reedy wrote:
> On 9/21/2013 10:30 PM, Guido van Rossum wrote:
>
>> Exceptions in __del__ point to bugs (sometimes in the stdlib) that
>> should be fixed, period. The only reason they do not result in
>> exceptions that are properly
On Sun, Sep 22, 2013 at 11:44 AM, Eli Bendersky wrote:
>
> On Sun, Sep 22, 2013 at 11:40 AM, Guido van Rossum wrote:
>
>> On Sun, Sep 22, 2013 at 10:25 AM, Eli Bendersky wrote:
>>
>>>
>>> I think there's a general agreement in this thread that we don
ld if you're writing code that's worth
documenting at all.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailma
On Sun, Sep 22, 2013 at 5:07 PM, Steven D'Aprano wrote:
> If you're going to the source to read docstrings, you're doing it wrong
> :-)
>
Be that as it may, when I'm reading the source I'm grateful for docstrings.
*And* I'm grateful when they are short.
--
On Sun, Sep 22, 2013 at 5:31 PM, Steven D'Aprano wrote:
> On Sun, Sep 22, 2013 at 10:07:28AM -0700, Guido van Rossum wrote:
>
> > Authors writing 3rd party packages can do what they want.
> >
> > But for the stdlib it's been settled for ages: docstrings should
ttributes without making
Color.red.blue work, go for it. If you can't, that's fine too. Users should
(obviously) steer clear from relying on either behavior.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy wrote:
> On 9/22/2013 10:04 PM, Guido van Rossum wrote:
>
> If I had the final word, I'd recommend using the current docstrings as
>> the .rst contents and replacing the docstrings with the 1-2 line
>> function desc
ot;unraisable" sounds too technical, and "suppressed" is hardly right
given that it is printed...
Let's leave well enough alone.
--Guido
--
--Guido van Rossum (on iPad)
___
Python-Dev mailing list
Python-Dev@python.org
https://mai
anyone using them IMHO.
>
Depends on how you define "class sttribute".
--Guido
--
--Guido van Rossum (on iPad)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Mon, Sep 23, 2013 at 4:27 AM, Walter Dörwald wrote:
> It would be great if the docstring contained a link to the online
> documentation.
>
That would have to be a feature of help(), not hardcoded in each docstring.
--
--Guido van Rossum (python.o
On Mon, Sep 23, 2013 at 12:57 AM, Larry Hastings wrote:
> On 09/23/2013 03:44 AM, Guido van Rossum wrote:
>
> On Sun, Sep 22, 2013 at 7:25 PM, Terry Reedy wrote:
>
>> I am gradually changing Idle docstrings, though only Idle developers will
>> ever see them. Writing a
was weird (yes I am aware that they
> are not actually class level properties but everywhere else Enum works hard
> to make it look like they are. See for instance the __dir__ method:
> http://hg.python.org/cpython/file/ed011b0d7daf/Lib/enum.py#l242).
>
Sorry to burst your bubble, but
On Mon, Sep 23, 2013 at 8:16 AM, Steven D'Aprano wrote:
> On Mon, Sep 23, 2013 at 07:53:00AM -0700, Guido van Rossum wrote:
>
> > there is no rule that because you can
> > access something on the class you should be able to access it on the
> > instance. Try askin
parameter
for this to work. But to me that's a problem with Django, and not something
for which the Enum type should bend over backwards to cover up for. Given
that it's a Djano weakness, IMO the __class__ solution is reasonable
enough, although in theory it would allow having object.
10:46 AM, Stephen J. Turnbull wrote:
> Guido van Rossum writes:
> > On Mon, Sep 23, 2013 at 8:17 AM, Zero Piraeus wrote:
> >> On Mon, Sep 23, 2013 at 09:45:46AM -0400, Chris Lambacher wrote:
>
> >>> [...] An example of how this will be used in practice is:>
On Mon, Sep 23, 2013 at 10:52 AM, Terry Reedy wrote:
> On 9/23/2013 10:56 AM, Guido van Rossum wrote:
>
> I think 60 is just a guideline. In stdlib .py source code I want it not
>> to extend beyond the 79th column (see recent PEP 8 argument). For a
>>
>
> PEP 8
t for new users because if you're using Python 3.x theirs a high
> chance you'll
> need to port a library or two still.
>
Based on my day-to-day experience this is still very true. (And yes, I'm
slowly turning the tide. But it will take a long time and I am committed to
return type of start_serving() or the choice of yield-from over yield on
python-tulip.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
rt in that package -- but
it still uses threads to wait for things.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.or
to look at multiple
trackers. Possibly the Tulip tracker could be limited to discussion of the
Python 3.3 backport that I hope to maintain in that project.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://
So, with the naming settled (asyncio it is), and lots of other things still
to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunteered
I'll have to accept my own PEP at some point, but I don't really *want* to
do that.
--
--Guido van Rossum (python.
archives. Also,
I'm not sure where the paranoia comes from. FWIW I'm less worried about
Google reading my personal email than about the python.org webmasters
reading it.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-
On Sun, Sep 29, 2013 at 10:16 AM, Antoine Pitrou wrote:
> On Sun, 29 Sep 2013 09:54:39 -0700 Guido van Rossum
> wrote:
> > So, with the naming settled (asyncio it is), and lots of other things
> still
> > to do, I need a BDFL for PEP 3156. Any volunteers? If no-one volunte
can select a different algorithm themselves.
>
> Christian
>
> [1] http://www.python.org/dev/peps/pep-0456/
> [2] https://twitter.com/EDEADLK/status/385572395777818624
>
> ___
> Python-Dev mailing list
> Python-Dev@pyt
On Thu, Oct 3, 2013 at 12:23 PM, Christian Heimes wrote:
> Am 03.10.2013 21:05, schrieb Guido van Rossum:
> > Hm. I would like to stick to the philosophy that Python's hash
> > should be as fast as it possibly can be, and should not be mistaken
> > for a cryptogra
On Thu, Oct 3, 2013 at 12:55 PM, Christian Heimes wrote:
> Am 03.10.2013 21:45, schrieb Guido van Rossum:
> > But fixing that shouldn't need all the extra stuff you're
> > proposing.
>
> I have proposed some of the extra stuff for more flexibility, the rest
> i
platform support for SipHash is slightly
> narrower, we need to keep the existing hash algorithm around, make it
> relatively easy to enable and ensure we continue to test it on the build
> bots.
>
> I believe that last requiremen
On Thu, Oct 3, 2013 at 11:20 PM, Armin Rigo wrote:
> Hi Guido,
>
> On Thu, Oct 3, 2013 at 10:47 PM, Guido van Rossum
> wrote:
> > Sounds a bit like some security researchers drumming up business. If you
> can
> > run the binary, presumably you can also recover the s
hey want users to feel the pain so they'll
buy a new device.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/op
30 PM, Tim Delaney wrote:
> On 9 October 2013 03:35, Guido van Rossum wrote:
>
>> On Tue, Oct 8, 2013 at 8:33 AM, R. David Murray wrote:
>>
>>> PS: I have always thought it sad that the ready availability of memory,
>>> CPU speed, and disk space tends to result
/**mailman/listinfo/python-dev<https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: https://mail.python.org/**mailman/options/python-dev/**
> guido%40python.org<https://mail.python.org/mailman/options/python-dev/guido%40python.org>
>
--
--Guido van Rossum (python.
; Sounds like you are suggesting we get a raspberry pi. All sorts of dumb
> waste shows up when you run code on those.
> El oct 8, 2013 4:46 p.m., "Guido van Rossum" escribió:
>
>> Let's agree to disagree then. I see your methodology used all around me
>> with ofte
er to accepted PEPs.
>
> I don't know yet how it can be implemented at server side.
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsub
Hm. I think at that scale giving every PEP a unique name and remembering
those names is just as hard. And the issue with different versions or
variants of the same idea is real. I think it's not worth the effort.
On Fri, Oct 11, 2013 at 5:53 PM, Victor Stinner wrote:
> 2013/10/12 G
__
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
That may be, but it's not completely irrelevant -- the push for getting
Tulip checked in was motivated by exactly the same deadline.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
os.path is special. The behavior of other modules is intentional.
In general it is not a good idea to automatically import all submodules
when you import a top-level package; imaging what this would do if you have
a large top-level package (maybe a namespace package) containing hundreds
of mod
n
> numbers are not stable accross clones.
> http://mercurial.selenic.com/wiki/RevisionNumber
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/
e-safe (or
task-safe?) seems a small step.
I'd be more worried about context manager that use thread-local state --
there is no similar concept in Tulip.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.or
On Thu, Oct 17, 2013 at 3:51 PM, Oscar Benjamin
wrote:
> On 17 October 2013 20:01, Guido van Rossum wrote:
> > On Thu, Oct 17, 2013 at 11:55 AM, Oscar Benjamin
> > wrote:
> >>
> >> On 17 October 2013 19:40, Xavier Morel wrote:
> >> > I think there&
king Python 3.3
setup would be useful, although you'd have to check out the Tulip repo and
run the tests from there.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
18/10/2013 5:31pm, Guido van Rossum wrote:
>
>> I'm working from home today and my Windows laptop is in the office, so I
>> won't be able to test my latest Tulip changes on Windows (I just renamed
>> pause to pause_reading, and hope to commit pause_reading
We should definitely keep supporting MSVC.
--Guido (mobile)
On Jun 7, 2016 12:39 PM, "Sturla Molden" wrote:
> Victor Stinner wrote:
>
> > Is it worth to support a compiler that in 2016 doesn't support the C
> > standard released in 1999, 17 years ago?
>
> MSVC only supports C99 when its needed
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
going to block on me is probably
when I'm rebooting a development VM and wondering why it's so slow.
Maybe we can put in a warning when getrandom(..., GRND_NONBLOCK) returns
EAGAIN? And then award a prize to people who can make it print th
a new exception.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
;
> > On 06/09/2016 08:52 AM, Guido van Rossum wrote:
> >
> >> That leaves direct calls to os.urandom(). I don't think this should
> block
> >> either.
> >
> >
> > Then it's you and me against the rest of the world ;-)
> >
> >
&
1801 - 1900 of 6462 matches
Mail list logo
