Hello all,
Buggy or not it's quite handy and as I said I use both when programming in
python. To discontinue it is just not a good idea.
Hausburn___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Carl -
> Changing the directory name is in fact a new and different (and much
> more invasive) special case, because distutils et al install scripts
> there, and that directory name is part of the distutils install scheme.
> Installers don't care where the Python binary is located, so moving it
>
On 3/16/2012 3:38 AM, Paul Moore wrote:
> On 16 March 2012 00:12, Carl Meyer wrote:
>> Changing the directory name is in fact a new and different (and much
>> more invasive) special case, because distutils et al install scripts
>> there, and that directory name is part of the distutils install sch
On 3/16/2012 10:53 AM, Paul Moore wrote:
> The only way I can read this to make sense is that you somehow
> consider the Python installation as part of your development
> environment (you mentioned source control earlier in the thread -
> surely you don't manage your Python installation in source c
On 3/16/2012 11:57 AM, Glenn Linderman wrote:
> So I think I'm finally beginning to see the underlying reason why Van is
> desiring this consistency: It is not that he wants to check in his
> installation of Python, but that he wants to check in his installation
> of his pac
On 3/20/2012 5:48 AM, Mark Hammond wrote:
> While I'm still unclear on the actual benefits of this, Martin's
> approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
discussion.
A question for you Mark, Paul, (a
On 3/20/2012 1:19 PM, Paul Moore wrote:
> Somewhat. I don't really object to #1, but mildly object to #2. I also
> note that the proposals round the Lib directory seem to have
> disappeared. I assume those have been dropped - they were the ones I
> did object to.
They are of secondary importance t
On 3/20/2012 3:31 PM, Paul Moore wrote:
> Serious question: Given a brand new PC, if you were installing Python
> 2.7, 3.2, 3.3a1, jython, and pypy, what would you do (beyond simply
> running 5 installers) to get your environment set up the way you want?
I install each python in its own directory:
cussion, Guido.
>
> As a footnote, distutils is already broken in 3.3. Now we give users or
> system administrators the possibility to edit the install schemes at
> will in sysconfig.cfg, but distutils hard-codes the old scheme. I tend
> to think it should be fixed, to make the distu
hi,
I got the error below during installing the libmobiledevice:
checking consistency of all components of *python development environment...
no*
configure: error:
Could not link test program to Python. Maybe the main Python library has
been
installed in some non-standard library path. If so,
gt;
> Antoine.
>
>
>
> ___
> 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
email) to appropriate persons.
>
> --
> Terry Jan Reedy
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/op
It's a reference to Neil Stephenson's Anathem.
On Jul 7, 2014 8:55 AM, "Benjamin Peterson" wrote:
> On Mon, Jul 7, 2014, at 08:44, Guido van Rossum wrote:
> > It would still be nice to know who "the appropriate persons" are. Too
> > much
> > of
dy has ever heard of.
On Tue, Jul 8, 2014 at 12:33 AM, Donald Stufft wrote:
>
> On Jul 8, 2014, at 12:58 AM, Nick Coghlan wrote:
>
>
> On 7 Jul 2014 10:47, "Guido van Rossum" wrote:
> >
> > It would still be nice to know who "the appropriate persons&qu
___
>> 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/
>> brett%40python.org
>>
>
>
//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
__
> 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)
___
droid? In particular, I'd
expect platform.linux_distribution() to return a clue that it's Android.
There should also be clues in /etc/lsb-release (assuming Android supports
it :-).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Pyt
Right.
On Saturday, August 2, 2014, Phil Thompson
wrote:
> On 02/08/2014 7:36 pm, Guido van Rossum wrote:
>
>> On Sat, Aug 2, 2014 at 12:53 AM, Phil Thompson <
>> p...@riverbankcomputing.com>
>> wrote:
>>
>> To me the issue is whether, for a particular
On Sat, Aug 2, 2014 at 12:14 PM, Shiz wrote:
> Guido van Rossum wrote:
> > sys.platform is for a broad indication of the OS kernel. It can be
> > used to distinguish Windows, Mac and Linux (and BSD, Solaris etc.).
> > Since Android is Linux it should have the same sys.platfo
quite clear about its value on Linux systems). Googling terms like "is
Android Linux" suggests that there is considerable controversy about the
issue, so I suggest you don't wait. :-)
On Sat, Aug 2, 2014 at 3:49 PM, Shiz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash:
e new method before calling
it) and leave poor sys.platform alone.
On Sat, Aug 2, 2014 at 10:18 PM, Shiz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Guido van Rossum wrote:
> > Well, it really does look like checking for the presence of those
> > ANDROID_*
On Sun, Aug 3, 2014 at 10:16 AM, Phil Thompson
wrote:
> On 03/08/2014 4:58 pm, Guido van Rossum wrote:
>
>> But *are* we going to support Android officially? What's the point? Do you
>> have a plan for getting Python apps to first-class status in the App Store
>> (
es to represent "a file", "a
> directory", "a non-existing file", etc.)
>
> Regards
>
> Antoine.
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listi
spam,
> > open('eggs') as eggs):
> > pass
>
> The parentheses seem unnecessary/redundant/weird. Why not allow
> newlines in-between "with" and the terminating ":"?
>
> with open('foo') as fo
The enemy must be documented and exported, since users will encounter them.
On Aug 14, 2014 4:54 AM, "Nick Coghlan" wrote:
> On 14 August 2014 19:25, Victor Stinner wrote:
> > Hi,
> >
> > IMO we should not document enum types because Python implementations
> other
> > than CPython may want to im
> handled
> as an ``iterbytes(data)`` *builtin*, that used ``data.__iterbytes__()``
> if defined, but otherwise fell back to ``map(bytes.byte, data)``::
>
> for x in iterbytes(data):
> # x is a length 1 ``bytes`` object, rather than an integer
> # Th
folks
won't be going off on their own to design a whole new language and name it
Python 4, following Larry Wall's Perl 6 example?
I think it makes sense to occasionally remind the more eager contributors
that we want the future to come gently (that's not to say in our slee
I think this would be a great topic for a blog post. Once you've written it
I can even bless it by Tweeting about it. :-)
PS. Why isn't PEP 387 accepted yet?
On Sat, Aug 16, 2014 at 8:48 PM, Nick Coghlan wrote:
> On 17 August 2014 12:43, Guido van Rossum wrote:
> > On Sat
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
; I value similar interfaces for bytes and
bytearray pretty highly.
I'm lukewarm on bytes.byte(c); but bytes([c]) does bother me because a size
one list is (or at least feels) more expensive to allocate than a size one
bytes object. So, okay.
--
--Guido van Rossum (python.org/~guido)
_
On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw wrote:
> On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
>
> >(Don't understand this to mean that we should never deprecate things.
> >Deprecations will happen, they are necessary for the evolution of any
> >program
On Tue, Aug 19, 2014 at 5:25 AM, Nick Coghlan wrote:
> On 18 August 2014 10:45, Guido van Rossum wrote:
> > On Sun, Aug 17, 2014 at 5:22 PM, Barry Warsaw wrote:
> >>
> >> On Aug 18, 2014, at 10:08 AM, Nick Coghlan wrote:
> >>
> >> >There's
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
ht
oding. Hence the occasional need for bytes arguments. But
most of the time you don't have to think about that, and forcing users to
worry about it is mostly as counter-productive as forcing to think about
the encoding of every text file.
--
--Guido van Rossum (python.
n of things they think of as binary blobs. Not worth the
> hassle to even seriously propose removing those APIs IMO.
But maybe we don't have to add new ones?
--Guido
--
--Guido van Rossum (on iPad)
___
Python-Dev mailing list
Python-Dev@
also giving me plenty of motivation to
> get back to working on PEP 432 (the rewrite of the interpreter startup
> sequence) for Python 3.5. A lot of these things are just plain hard to
> change because of the complexity of the current startup code.
> Redesigning that to use a cleaner, multiphas
issue18814#msg225791
>
> Regards,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-d
thon.org -- sooner or later some forgotten part of our
infrastructure *will* come under attack.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http
On Wed, 3 Sep 2014 10:54:55 -0700
> Guido van Rossum wrote:
> >
> > Let's take the plunge on this issue for the next 2.7 release (3.5 being a
> > done deal).
>
> I'm entirely against this.
>
> > Yes, some people will find that they have an old script
&g
19:54, Guido van Rossum wrote:
> > Let's take the plunge on this issue for the next 2.7 release (3.5 being
> > a done deal). Yes, some people will find that they have an old script
> > accessing an old service which breaks. Surely some of the other changes
> > in the sa
that's going to be the least of your security concerns".
>
Yeah, I am not interested in helping out the case where the user is
incapable (for whatever reason) of tracking down and changing a couple of
lines of code. Such users are dependent on someone else with wizard powers
anyway (who gave
I will pronounce for 3.4 once you point me to the documentation that
explains how to disable cert validation for an example program that
currently pulls down an https URL using urlopen. Without adding package
dependencies.
On Mon, Sep 8, 2014 at 10:25 AM, Alex Gaynor wrote:
> Guido van Ros
ontext = ssl.create_default_context()
> context.verify_mode = CERT_OPTIONACERT_NONE
> context.verify_hostname = False
> urllib.request.urlopen("
> https://something-i-apparently-dont-care-much-about";, context=context)
>
> Alex
>
>
> On Mon, Sep 8, 2014 at 10:35 AM, Guido
ng then I think documentation is more than enough.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/m
er as the monkey-patch
> option?
>
> So after the (global to the module) monkeypatch, they would _still_ have
> to add the keyword parameter.
>
>
>
> On 9/8/2014 4:31 PM, Guido van Rossum wrote:
>
> I still prefer having a parameter on urlopen (or thereabouts) -- it feels
&g
/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsub
cyURLOpener(context=ssl._create_unverified_context())
>
> And to revert to the old default behaviour globally:
>
> import ssl
> ssl._create_https_context = ssl._create_unverified_context
>
> The backport to 2.7 would then be a matter of bringing urllib,
> urllib
?
>>>
>>> I even raised it in stackoverflow
>>> http://stackoverflow.com/questions/25840177/list-
>>> insert-at-index-that-is-well-out-of-range-behaves-like-append
>>>
>>> and got some responses .
>>>
>>
>> Hello Har
mpty string if s is
shorter than 100.
> Although shouldn't that read s[i:i+1] = [x] ?
>
Should've stopped while you were ahead. :-)
'Nuff said.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@pyt
> > maybe Python 4 can reclaim /usr/bin/python.
>
> I expect not quite. Perhaps 10 years though.
>
>
>
> --
> Steven
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailma
On Sep 19, 2014 8:36 AM, "Antoine Pitrou" wrote:
>
> On Fri, 19 Sep 2014 08:20:48 -0700
> Guido van Rossum wrote:
> > "python" should always be the same as "python2".
>
> "Always" as in "et
ing 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 maili
is du jour, without sufficient time
> being available for regular infrastructure maintenance tasks.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
--
--Guido van Rossum (python.org/~guido)
___
, 2014 at 8:54 AM, Alex Gaynor wrote:
> Done and done.
>
> Alex
>
> On Fri, Sep 19, 2014 at 4:13 PM, Guido van Rossum
> wrote:
>
>> +1 on Nick's suggestion. (Might also mention that this is the reason why
>> both functions should exist and have compatible si
e banner of PEP 476 for
> backporting to the maintenance branches.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
--
--Guido van Rossum (python.org/~guido)
___
Python-
OK, I'll hold off a bit on approving the PEP, but my intention is to
approve it. Go Alex go!
On Sat, Sep 20, 2014 at 4:03 PM, Nick Coghlan wrote:
> On 21 September 2014 08:22, Guido van Rossum wrote:
> > Sounds good. Maybe we should put the specifically targeted releases in
That is copying the (alt)install targets of Python's own Makefile, and I
think those are exactly right.
On Oct 3, 2014 3:07 PM, "Donald Stufft" wrote:
> I'm working on the backport of ensurepip to Python 2.7, and I realized that
> I'm not sure which commands to install. Right now by default pip (
t's fine with me, just wanted
> to
> make sure it made sense for Python 2.x. Thanks!
>
> On Oct 3, 2014, at 8:31 PM, Guido van Rossum wrote:
>
> That is copying the (alt)install targets of Python's own Makefile, and I
> think those are exactly right.
> On Oct 3, 20
Yes.
On Friday, October 3, 2014, Donald Stufft wrote:
> Whoops, I misred.
>
> So to be clear, you think:
>
> install -> pip, pip2, pip2.7
> altinstall -> pip2.7
>
> On Oct 3, 2014, at 8:46 PM, Guido van Rossum > wrote:
>
> That's not what I meant.
On 10 October 2014 02:29, Victor Stinner wrote:
> The free version (Visual Studio Express) only supports 32-bit
>
VC++ 2008/2010 EE do not *bundle* a 64-bit compiler, but it's certainly
possible to build 64-bit applications by using the compiler in the (also
free) Windows SDK:
http://jenshuebel
!
On Fri, Oct 3, 2014 at 2:57 PM, Alex Gaynor wrote:
> Guido van Rossum python.org> writes:
>
> >
> > OK, I'll hold off a bit on approving the PEP, but my intention is to
> approve
> > it. Go Alex go!
> >
>
> A patch for the environmental variable
o ask
their selector (or whatever they use) to wait for the underlying FD and
then they can try again.
(Alternatively, we could raise BlockingIOError, which is that the OS level
read() raises if there's no data immediately available on a non-blocking
FD; but it seems that streams ha
any
> mai...@de.ibm.com, +49-7031-16-3654
>
> IBM Deutschland Research & Development GmbH
> Vorsitzende des Aufsichtsrats: Martina Koederitz
> Geschaeftsfuehrung: Dirk Wittkopp
> Sitz der Gesells
Hm. I've never been a fan of that. EIBTI and such...
On Tue, Oct 21, 2014 at 10:53 AM, Barry Warsaw wrote:
> On Oct 21, 2014, at 10:13 AM, Guido van Rossum wrote:
>
> >For new code, and whenever you have an opportunity to refactor old code,
> >you should use new-style
dule.c:
>
>
>
> --- a/Modules/pwdmodule.c 2014-05-19 00:19:39.0 -0500
>
> +++ b/Modules/pwdmodule.c 2014-10-21 18:00:35.676331205 -0500
>
> @@ -57,6 +57,10 @@
>
>}
>
> }
>
>
>
> +#if defined(HAVE_BROKEN_GECOS_FIELD)
>
> +static ch
e out the inconsistencies between tools so we can document and
> work
> > through them.
> >
> > Having different builds of CPython out there will only fragment the
> > community and hurt extension authors far more than it may seem to hel
hon-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/stefan.richthofer%40gmx.de
> >
> ___
> Python-Dev m
On Mon, Oct 27, 2014 at 10:48 AM, Paul Moore wrote:
> The bad news is that the support added to the old 32-bit mingw to
> support linking to alternative C runtime libraries (specifically
> -lmsvcr100) has bitrotted, and no longer functions correctly in
> mingw-w64. As a result, not only can mingw-
0475/
>
> Victor
> ___
> 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
>
Gotta be brief, but NotImplemented is for all binary ops. Power may be an
exception because it's ternary?
On Nov 3, 2014 8:08 AM, "Brett Cannon" wrote:
>
>
> On Mon Nov 03 2014 at 5:31:21 AM Ethan Furman wrote:
>
>> Just to be clear, this is about NotImplemented, not NotImplementedError.
>>
>>
Not those.
On Nov 3, 2014 8:56 AM, "Antoine Pitrou" wrote:
> On Mon, 3 Nov 2014 08:48:07 -0800
> Guido van Rossum wrote:
> > Gotta be brief, but NotImplemented is for all binary ops.
>
> Even in-place ops?
>
> Regards
>
> Antoine.
>
>
> >
ow if
the byte code interpreter looks for Not implemented from __iop__.
On Nov 3, 2014 9:00 AM, "Guido van Rossum" wrote:
> Not those.
> On Nov 3, 2014 8:56 AM, "Antoine Pitrou" wrote:
>
>> On Mon, 3 Nov 2014 08:48:07 -0800
>> Guido van Rossum wrote:
>&
That must be so that an immutable type can still implement __iop__ as an
optimization.
On Mon, Nov 3, 2014 at 9:10 AM, Antoine Pitrou wrote:
> On Mon, 3 Nov 2014 09:05:43 -0800
> Guido van Rossum wrote:
> > Sorry, was too quick. For immutable types __iop__ may not exist and
hon-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
U
be okay if it *did* raise).
--
--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
; * Check for None object dereferences
>
> Thanks a lot,
> Stefan Bucur
>
> [1] http://clang-analyzer.llvm.org/available_checks.html
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/list
Please also check python-static-type-check...@googlegroups.com.
On Nov 18, 2014 3:06 AM, "Stefan Bucur" wrote:
> Thanks for the pointer! There seem indeed to be more formal analysis tools
> for JavaScript than for Python (e.g., the most recent one for JS I know of
> is the Jalangi framework [1]).
not until we've had a review
here at python-dev. I would like to thank Chris Angelico for writing the
original PEP draft.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/list
drafting these additions?
On Thu, Nov 20, 2014 at 2:05 AM, Nick Coghlan wrote:
> On 20 November 2014 06:15, Benjamin Peterson wrote:
>
>>
>> On Wed, Nov 19, 2014, at 15:10, Guido van Rossum wrote:
>> > There's a new PEP proposing to change how to treat StopIt
from" PEP). How about "generate_escape"?
>>
>
> Or may be "generator_stop_iteration"?
>
Or just "generator_stop"?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Nov 20, 2014 at 3:13 PM, Antoine Pitrou wrote:
> On Thu, 20 Nov 2014 14:04:24 -0800
> Guido van Rossum wrote:
>
> > On Thu, Nov 20, 2014 at 12:13 PM, Serhiy Storchaka
> > wrote:
> >
> > > On 20.11.14 21:58, Antoine Pitrou wrote:
> > >
&g
er iterator (though it also has a few others -- send(), throw(),
close()). However *inside* they are not at all similar -- generators
produce a value is done through "yield", __next__() methods use return.
Even if we end up rejecting the PEP we should campaign for better
understanding of
lass of StopIteration -- but it doesn't really
have to be, it could be a different exception (like in Tornado).
So I haven't found any framework that recommends "raise StopIteration(v)".
Sure, some frameworks will have to be changed, but they have until
Like it or not, github is easily winning this race.
--
--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
On Fri, Nov 21, 2014 at 9:26 PM, Tshepang Lekhonkhobe
wrote:
> On Fri, Nov 21, 2014 at 8:46 PM, Guido van Rossum
> wrote:
> > Like it or not, github is easily winning this race.
>
> Are you considering moving CPython development to Github?
>
No, but I prefer it for new p
is the right thing
going forward.
--
--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
moving to
GitHub. For PEPs I've noticed that for most PEPs these days (unless the
primary author is a core dev) the author sets up a git repo first anyway,
and the friction of moving between such repos and the "official" repo is a
pain.
--
--Guido van
On Saturday, November 22, 2014, Nick Coghlan wrote:
> On 23 November 2014 at 15:19, Guido van Rossum > wrote:
> > This thread seems to beg for a decision. I think Donald Stufft has it
> > exactly right: we should move to GitHub, because it is the easiest to use
> > and m
b. I
promise you that once the pain of the switch is over you will feel much
better about it. I am also convinced that we'll get more contributions this
way.
Note: I am not (yet) proposing we switch CPython itself. Switching it would
be a lot of work, and it is specifically out of scope for th
nothing except improving the
> documentation of next(). Explain that it can raise StopIteration which, if
> allowed to propogate can cause premature exhaustion of an iterator.
>
> If something must be done then I would suggest changing the behaviour of
> next() for an exhausted i
man pages got to the point where I basically use
> Google to ask my questions, then bookmark the solutions I find (which often
> turn out to be on stackoverflow).
>
Then there's this. http://git-man-page-generator.lokaltog.net/
--
--Guido van Rossum (on iPad)
_
On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher
wrote:
> On 11/23/14, Guido van Rossum wrote:
>
> > It wouldn't be so bad if we had the occasional generator author writing
> "raise StopIteration" instead of "return" to exit from a generator. (We
> c
On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher
wrote:
> On 11/24/14, Guido van Rossum wrote:
> > On Mon, Nov 24, 2014 at 8:14 AM, Isaac Schwabacher <
> ischwabac...@wisc.edu(javascript:main.compose()> wrote:
> >
> > > On 11/23/14, Guido van Rossum wrote:
&g
On Mon, Nov 24, 2014 at 3:07 PM, Isaac Schwabacher
wrote:
> On 11/24/14, Guido van Rossum wrote:
> > On Mon, Nov 24, 2014 at 1:32 PM, Isaac Schwabacher <
> ischwabac...@wisc.edu
> ischwabac...@wisc.edu> wrote:
> >
> > > On 11/24/14, Guido van Rossum wrote:
On Mon, Nov 24, 2014 at 4:21 PM, Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
>
> On Wed, Nov 19, 2014 at 3:10 PM, Guido van Rossum
> wrote:
>
>> There's a new PEP proposing to change how to treat StopIteration bubbling
>> up out of a generator
or. I'll clarify this in the PEP (even though it
logically follows from the proposal) -- I don't think there's anything to
worry about.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.py
On Tue, Nov 25, 2014 at 10:12 AM, Isaac Schwabacher
wrote:
> On 11/25/14, Guido van Rossum wrote:
> > On Tue, Nov 25, 2014 at 9:49 AM, Chris Angelico ros...@gmail.com')" target="1">ros...@gmail.com> wrote:
> >
> > > On Wed, Nov 26, 2
ons escaping
> from generators, but the PEP should sell the idea on that basis, not
> on what sounds like a false promise that it will make comprehensions
> and generators behave identically.
>
I will weaken that language.
--
--Guido van Rossum (python.org/~guido)
not just a demonstration.
If you want to try though, I'm happy to entertain a pull request for the
PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
1 - 100 of 6462 matches
Mail list logo
