On Sun, Jun 22, 2014 at 8:00 AM, Steve Dower wrote:
> We can always lie about the version in sys.version. Existing code is
> unaffected and new code will have to use version_info (Windows developers
> will know that Windows pulls tricks like this every other version... doesn't
> make it a great id
On Sun, Jun 22, 2014 at 7:37 AM, M.-A. Lemburg wrote:
> There are no places in the stdlib that parse sys.version in a
> way that would break wtih 2.7.10, AFAIK. I was just referring
> to the statement that Nick quoted. sys.version *is* used for
> parsing the Python version or using parts of it to
On Tue, Jun 24, 2014 at 6:42 AM, "Martin v. Löwis" wrote:
> See my other message. It's actually heavier, since it requires changes
> to distutils, PyPI, pip, buildout etc., all which know how to deal with
> Python minor version numbers, but are unaware of the notion of competing
> ABIs on Windows
On Thu, Jun 26, 2014 at 9:04 PM, Antoine Pitrou wrote:
> For the same reason, I agree with Victor that we should ditch the
> threading-disabled builds. It's too much of a hassle for no actual,
> practical benefit. People who want a threadless unicodeless Python can
> install Python 1.5.2 for all I
On Sat, Jun 28, 2014 at 11:05 PM, Akira Li <4kir4...@gmail.com> wrote:
> Have you considered adding support for paths relative to directory
> descriptors [1] via keyword only dir_fd=None parameter if it may lead to
> more efficient implementations on some platforms?
>
> [1]: https://docs.python.org
On Wed, Jul 2, 2014 at 7:20 AM, Paul Moore wrote:
> I think that thin wrapper is needed - even
> if the various bells and whistles are useful, they can be built on top
> of a low-level version (whereas the converse is not the case).
+1. Make everything as simple as possible (but no simpler).
Chr
On Tue, Jul 8, 2014 at 1:15 AM, Benjamin Peterson wrote:
> Why do you think that?
>
> % python
> Python 2.7.6 (default, May 29 2014, 22:22:15)
> [GCC 4.7.3] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
class x(object): pass
> ...
class y(object): pas
On Tue, Jul 8, 2014 at 11:59 AM, Rob Cliffe wrote:
> If I came across an int object and had no concept of what an integer number
> was, how would I know what its "value" is supposed to be?
The value of an integer is the number it represents. In CPython, it's
entirely possible to have multiple int
On Tue, Jul 8, 2014 at 1:12 PM, Steven D'Aprano wrote:
> Why? What value (pun intended) is there in adding an explicit statement
> of value to every single class?
>
> "The value of a str is the str's sequence of characters."
> "The value of a list is the list's sequence of items."
> "The value of
On Tue, Jul 8, 2014 at 5:01 PM, Stephen J. Turnbull wrote:
> I agree with Steven d'A that this rule is not part of the language
> definition and shouldn't be, but it's the rule of thumb I find hardest
> to imagine *ever* wanting to break in my own code (although I sort of
> understand why the IEEE
On Tue, Jul 8, 2014 at 5:53 PM, Stephen J. Turnbull wrote:
> But you're missing at least two alternatives that
> involve raising on some calculations involving NaN, as well as the
> fact that forcing inequality of two NaNs produced by equivalent
> calculations is arguably just as wrong as allowing
On Wed, Jul 9, 2014 at 3:00 AM, Steven D'Aprano wrote:
> On Tue, Jul 08, 2014 at 04:58:33PM +0200, Anders J. Munch wrote:
>
>> For two NaNs computed differently to compare equal is no worse than 2+2
>> comparing equal to 1+3. You're comparing values, not their history.
>
> a = -23
> b = -42
> if
On Mon, Jul 14, 2014 at 12:04 AM, Jason R. Coombs wrote:
> I can achieve what I need by constructing a set on the ‘items’ of the dict.
>
set(tuple(doc.items()) for doc in res)
>
> {(('n', 1), ('err', None), ('ok', 1.0))}
This is flawed; the tuple-of-tuples depends on iteration order, which
m
On Mon, Jul 14, 2014 at 2:23 AM, Steven D'Aprano wrote:
>> We will see
>> later that that happens. Further, when comparing float NaNs of the same
>> identity, the list implementation forgot to special-case NaNs. Which
>> would be a bug, IMHO.
>
> "Forgot"? I don't think the behaviour of list compa
On Mon, Jul 14, 2014 at 4:11 AM, Nick Coghlan wrote:
> What we've never figured out is a good place to *document* it. I
> thought there was an open bug for that, but I can't find it right now.
Yeah. The Py3 docs explain why "x in [x]" is True, but I haven't found
a parallel explanation of sequenc
On Sun, Aug 10, 2014 at 10:44 AM, Steven D'Aprano wrote:
> Looking at your comment here:
>
>> [1]: https://news.ycombinator.com/item?id=8154471
>
> there is a reply from zeckalpha, who says:
>
>"Actually, leaving out `object` is the preferred convention for
> Python 3, as they are semantic
On Mon, Aug 11, 2014 at 9:40 PM, Peter Otten <__pete...@web.de> wrote:
> Read again. The OP tries to delegate attribute lookup to an (existing)
> attribute.
>
> IMO the root cause of the problem is that pickle looks up __dunder__ methods
> in the instance rather than the class.
The recursion comes
On Wed, Aug 13, 2014 at 11:11 PM, Isaac Morland wrote:
> While I would not claim a Python sandbox is utterly impossible, I'm
> suspicious that the whole "consenting adults" approach in Python is
> incompatible with a sandbox. The whole idea of a sandbox is to absolutely
> prevent people from doin
On Thu, Aug 14, 2014 at 2:58 AM, Steven D'Aprano wrote:
>> It's certainly not *fundamentally* impossible to sandbox Python.
>> However, the question becomes one of how much effort you're going to
>> go to and how much you're going to restrict the code.
>
> I believe that PyPy has an effective sand
On Sat, Aug 16, 2014 at 10:47 PM, Marko Rauhamaa wrote:
>
> You might be able to have it bothways. You could have:
>
>with (open(name) for name in os.listdir("config")) as files:
But that's not a tuple, it's a generator. Should generators be context
managers? Is anyone seriously suggesting th
On Sat, Aug 23, 2014 at 6:17 AM, Glenn Linderman wrote:
> "cp1251 of utf-8 encoding" is non-sensical. Either it is cp1251 or it is
> utf-8, but it is not both. Maybe you meant "or" instead of "of".
I'd assume "or" meant there, rather than "of", it's a common typo.
Not sure why 1251, specifically
On Sat, Aug 23, 2014 at 8:26 AM, Oleg Broytman wrote:
> On Sat, Aug 23, 2014 at 07:04:20AM +1000, Chris Angelico
> wrote:
>> On Sat, Aug 23, 2014 at 6:17 AM, Glenn Linderman
>> wrote:
>> > "cp1251 of utf-8 encoding" is non-sensical. Either it is cp1251 or
On Sat, Aug 23, 2014 at 7:02 PM, Stephen J. Turnbull wrote:
> Chris Barker writes:
>
> > So I write bytes that are encoded one way into a text file that's encoded
> > another way, and expect to be abel to read that later?
>
> No, not you. Crap software does that. Your MUD server. Oleg's
> fav
On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote:
> Not sure why. Just put another module named "ssl" in sys.modules directly.
> You can also monkeypatch the genuine ssl module.
That has to be done inside the same process. But imagine this
scenario: You have a program that gets invoked as ro
On Mon, Sep 1, 2014 at 11:34 PM, Antoine Pitrou wrote:
> On Mon, 1 Sep 2014 23:24:39 +1000
> Chris Angelico wrote:
>> On Mon, Sep 1, 2014 at 10:41 PM, Antoine Pitrou wrote:
>> > Not sure why. Just put another module named "ssl" in sys.modules directly.
>> &
On Wed, Sep 3, 2014 at 12:47 PM, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > Sorry, I haven't been a very good maintainer for that buildbot (the main
> > reason it never graduated to the "stable" list). If you send me your public
> > SSH key, I can add it (I think - if not, I can as
On Thu, Sep 4, 2014 at 3:32 AM, francis wrote:
>> does mean a measure of trust in some external entity, or else some
>> very careful rules (mainly firewall), which not every coder will know
>> about.
>
>
> Just curious, is there a way to mount the infrastructure the oder way
> around? One sets a s
On Thu, Sep 11, 2014 at 12:55 PM, Li Tianqing wrote:
> Hello,
> Can someone explain me why gc(CPython) can not collect recursive
> closure's cycle reference? There is no __del__ here, why gc can not
> collect?
Can you start by explaining what's not getting collected and what is?
Where's the
On Sun, Sep 14, 2014 at 8:13 PM, Brynjar Smári Bjarnason
wrote:
> I am using Python 3.4.1 installed with Anaconda. I tried the following
> (expecting an OrderedDict as result):
>
from collections import namedtuple
NT = namedtuple("NT",["a","b"])
nt = NT(1,2)
print(vars(nt))
> {}
>
On Tue, Sep 16, 2014 at 1:34 PM, Stephen J. Turnbull wrote:
> Jim J. Jewett writes:
>
> > In terms of best-effort, it is reasonable to treat the smuggled bytes
> > as representing a character outside of your unicode repertoire
>
> I have to disagree. If you ever end up passing them to something th
On Wed, Sep 17, 2014 at 1:00 AM, R. David Murray wrote:
> That isn't the case in the email package. The smuggled bytes are not
> errors[*], they are literally smuggled bytes.
But they're not characters, which is what Stephen and I were saying -
and contrary to what Jim said about treating them a
On Wed, Sep 17, 2014 at 3:46 AM, R. David Murray wrote:
>> You can't treat them as characters, so while you have them in your
>> string, you can't treat it as a pure Unicode string - it''s a Unicode
>> string with smuggled bytes.
>
> Well, except that I do. The email header parsing algorithms all
On Wed, Sep 17, 2014 at 3:55 AM, Jim Baker wrote:
> Of course, if you do actually have a smuggled isolated low surrogate
> FOLLOWED by a smuggled isolated high surrogate - guess what, the only
> interpretation is a codepoint. Or perhaps more likely garbage. Of course it
> doesn't happen so often,
On Wed, Sep 17, 2014 at 5:29 AM, R. David Murray wrote:
> Yes. I thought you were saying that one could not treat the string with
> smuggled bytes as if it were a string. (It's a string that can't be
> encoded unless you use the surrogateescape error handler, but it is
> still a string from Pyth
On Thu, Sep 25, 2014 at 6:50 AM, Steve Dower wrote:
> Donald Stufft wrote:
>> One thing about *nix is even though you can’t write to your normal Python
>> install location without root, invoking pip with permissions (assuming you
>> have
>> them) is as easy as prefacing it with ``sudo`` in most c
On Fri, Sep 26, 2014 at 9:53 AM, Antoine Pitrou wrote:
>> In other words, os.system is *already* an attack vector, unless you only
>> use it with trusted strings. I don't think the bash env vulnerability
>> adds to the attack surface.
>>
>> Have I missed something?
>
> The part where the attack pa
On Fri, Sep 26, 2014 at 10:29 AM, Devin Jeanpierre
wrote:
> As I understand it, if the attacker can help specify the environment
> (e.g. this is a CGI script), and you run os.system('echo hi'), you can
> get pwned. Even safe uses of os.system are vulnerable unless you point
> /bin/sh at a secure s
On Mon, Oct 6, 2014 at 6:49 AM, Terry Reedy wrote:
> I can access every page I have tried except for the tkinter and idle pages,
> which either give interminable 'Connecting...' or in one try, 404.
> https://docs.python.org/3/library/tkinter.html
> https://docs.python.org/3/library/idle.html
Is t
On Tue, Oct 7, 2014 at 4:33 AM, Skip Montanaro wrote:
> On Mon, Oct 6, 2014 at 12:24 PM, Ned Deily wrote:
>> So 2.7.x is not "security only" and wouldn't reach that stage until 2020
>> under current policy.
>
> Apparently no other 2.x release qualifies as "security only" at this
> point? I would
On Fri, Oct 10, 2014 at 11:52 AM, Jesus Cea wrote:
> Actually, it doesn't work in Python 2 either. It never supported
> international mailbox names.
>
> Should I dare to suggest to port this to 2.7, since 2.7 is special and
> will be supported for a long time?. Or maybe this is something like
> "Y
On Fri, Oct 10, 2014 at 3:05 PM, Glenn Linderman wrote:
> There are still lots of idiotic web sites that assume everything in front of
> the @ must be a letter, digit, dot, or hyphen, and even some that only
> permit one dot after the @... even though for 30 years or so, the RFCs have
> permitted
On Sat, Oct 11, 2014 at 2:45 AM, Jesus Cea wrote:
> On 03/09/14 02:37, Antoine Pitrou wrote:
>
>> I'm not sure that's an answer to the problem. What we need is not more
>> machines, but dedicated buildbot maintainers.
>
> I would love to get an email if my buildbots are consistently RED for a
> fe
On Sun, Oct 26, 2014 at 7:50 AM, Steve Dower wrote:
> Ray Donnelly wrote:
>> What is it that you
>> are afraid of if CPython can be compiled out of the box using
>> mingw/MinGW-w64? Why are you fighting so hard against having option.
>
> I'm afraid of users having numpy crash because they're using
On Sun, Oct 26, 2014 at 8:47 AM, Antoine Pitrou wrote:
> And how do you know that it would have worked with MSVC if you only use
> MinGW?
> If you want to ensure compatibility with MSVC, you must build with MSVC.
> There's no working around that.
Precisely. If you build with MinGW, you can't ensu
On Sun, Oct 26, 2014 at 8:59 AM, Antoine Pitrou wrote:
> How do you know this isn't a problem, since you haven't *tested* with
> MSVC?
> Why on Earth would you want to test your PEP work with an unsupported
> Windows compiler and runtime, rather than with the officially supported
> compiler and ru
On Sun, Oct 26, 2014 at 9:19 AM, Antoine Pitrou wrote:
> My point is that your "Windows build" would not have the same behaviour
> as a MSVC-produced Windows build, and so testing it with it would not
> certify that your code would actually be compatible with genuine
> MSVC builds of CPython, whic
On Thu, Oct 30, 2014 at 6:34 AM, Glenn Linderman wrote:
> (I'm actually not sure if *nix package managers allow multiple repositories
> or not, but from the way people talk about them, it always sounds like a
> "distribution" also provides "a repository" of additional packages).
I'm fairly sure t
On Thu, Nov 13, 2014 at 6:34 PM, Charles-François Natali
wrote:
> 2014-11-12 22:16 GMT+00:00 Buck Golemon :
>> This is due to the fix for issue21090, which aimed to un-silence errors
>> which previously went unheard. The fix is for me, as a user, to write a loop
>> that uses os.read and interprete
On Sun, Nov 16, 2014 at 2:40 AM, Paul Moore wrote:
> On 15 November 2014 15:17, Benjamin Peterson wrote:
>> On Sat, Nov 15, 2014, at 05:54, Nathaniel Smith wrote:
>>> On 15 Nov 2014 10:10, "Paul Moore" wrote:
>>> >
>>> > > Incidentally, it would be really useful if python.org provided stable
>>>
On Thu, Nov 20, 2014 at 7:48 AM, MRAB wrote:
> The PEP says """any generator that depends on an implicitly-raised
> StopIteration to terminate it will have to be rewritten to either catch
> that exception or use a for-loop"""
>
> Shouldn't that be "... explicitly-raised ...", because returning rai
On Thu, Nov 20, 2014 at 3:45 AM, Nick Coghlan wrote:
> The part I found most compelling was when you pointed out that in the
> special method implementations, the normal return path was always spelled
> with "return", while the "value missing" result was indicated with a special
> kind of exceptio
On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum wrote:
> It would also be useful if we could extend the PEP with some examples of the
> various categories of fixes that can be applied easily, e.g. a few examples
> of "raise StopIteration" directly in a generator that can be replaced with
> "retu
On Fri, Nov 21, 2014 at 9:04 AM, 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:
>>>
>>> To me "generator_return" sounds like the addition to generator syntax
>>> allowing for return statements (which was done as
On Fri, Nov 21, 2014 at 10:34 AM, Chris Angelico wrote:
> On Fri, Nov 21, 2014 at 6:36 AM, Guido van Rossum wrote:
>> It would also be useful if we could extend the PEP with some examples of the
>> various categories of fixes that can be applied easily, e.g. a few exampl
On Sat, Nov 22, 2014 at 12:47 AM, Raymond Hettinger
wrote:
> Also, the proposal breaks a reasonably useful pattern of calling
> next(subiterator) inside a generator and letting the generator terminate
> when the data stream ends. Here is an example that I have taught for
> years:
>
> def izi
On Sat, Nov 22, 2014 at 2:58 AM, Steven D'Aprano wrote:
> Since zip() is documented as
> halting on the shorter argument, it can't raise an exception. So what
> other options are there apart from silently consuming the value?
Sure, it's documented as doing that. But imagine something that isn't
a
On Sat, Nov 22, 2014 at 3:37 AM, Donald Stufft wrote:
> I don’t have an opinion on whether it’s enough of a big deal to actually
> change
> it, but I do find wrapping it with a try: except block and returning easier
> to understand. If you showed me the current code unless I really thought about
On Sun, Nov 23, 2014 at 6:49 AM, Ron Adam wrote:
>
> OPTION 1:
>
> Make comprehensions act more like generator expressions.
>
> It would mean a while loop in the object creation point is converted to a
> for loop. (or something equivalent.)
>
> Then both a comprehension and a generator expressions
On Sun, Nov 23, 2014 at 8:03 AM, Ron Adam wrote:
>> Making comprehensions work more like generator expressions
>> would, IMO, imply making the same change to all for loops: having a
>> StopIteration raised by the body of the loop quietly terminate the
>> loop.
>
>
> I'm not suggesting making any c
On Sun, Nov 23, 2014 at 7:30 AM, Raymond Hettinger
wrote:
> Legitimate Use Cases for Raising StopIteration in a Generator
>
>
> In a producer/consumer generator chain, the input generator signals
> it is done by raising StopIteration and
On Sun, Nov 23, 2014 at 11:05 AM, Ron Adam wrote:
> Se we have these...
>
> Tuple Comprehension (...)
> List Comprehension [...]
> Dict Comprehension {...} Colon make's it different from sets.
> Set Comprehension {...}
>
> I don't think there is any other way to create the
On Sun, Nov 23, 2014 at 11:51 AM, Ron Adam wrote:
>
>
> On 11/22/2014 06:20 PM, Chris Angelico wrote:
>>
>> Hmmm, there's no such thing as tuple comprehensions.
>
> Just didn't think it through quite well enough. But you are correct, that
> would be a ge
On Sun, Nov 23, 2014 at 12:11 PM, Raymond Hettinger
wrote:
> The worry is that your proposal intentionally breaks that code which is
> currently
> bug free, clean, fast, stable, and relying on a part of the API that has
> been
> guaranteed and documented from day one.
(I'd just like to mention th
On Sun, Nov 23, 2014 at 4:59 PM, Nick Coghlan wrote:
> The learning curve on git is still awful - it offers no compelling
> advantages over hg, and GitHub doesn't offer any huge benefits over
> BitBucket for Sphinx based documentation (ReadTheDocs works just as
> well with either service).
The le
On Sun, Nov 23, 2014 at 5:03 PM, Wes Turner wrote:
> hg imuutability is certainly a primarily attractive feature;
> along with the keyring support.
What exactly do you mean by immutability? Are you talking about how
git allows a "force push" that can destroy data? That can be rejected
in a repo's
On Mon, Nov 24, 2014 at 2:11 AM, Ethan Furman wrote:
> On 11/22/2014 08:53 PM, Guido van Rossum wrote:
>>
>> In order to save everyone's breath, I am *accepting* the proposal of PEP
>> 479.
>
> Excellent.
>
> Chris, thank you for your time, effort, and thoroughness in championing this
> PEP.
>
T
On Mon, Nov 24, 2014 at 5:28 AM, Ron Adam wrote:
> With the passage of the PEP, it will change what is different about them
> once it's in full effect. The stop hack won't work in both, and you may get
> a RuntimeError in generator expressions where you would get StopIteration in
> list-comps. (
On Mon, Nov 24, 2014 at 7:18 AM, Mark Shannon wrote:
> Hi,
>
> I have serious concerns about this PEP, and would ask you to reconsider it.
Hoping I'm not out of line in responding here, as PEP author. Some of
your concerns (eg "5 days is too short") are clearly for Guido, not
me, but perhaps I ca
On Mon, Nov 24, 2014 at 10:18 AM, Ron Adam wrote:
>> The stop hack won't work in either (currently it does work in
>> genexps), but you'd get a different exception type if you attempt it.
>> This is correct. It's broadly similar to this distinction:
>>
> >>>{1:2,3:4}[50]
>>
>> Traceback (most
On Mon, Nov 24, 2014 at 2:42 PM, Guido van Rossum wrote:
> Then there's this. http://git-man-page-generator.lokaltog.net/
Wow scarily accurate.
http://git-man-page-generator.lokaltog.net/#2d1a13476a5f32c4db27fd7aa89a84f3
Anything to do with git submodules is virtually impossible to
disting
On Wed, Nov 26, 2014 at 2:20 AM, Steven D'Aprano wrote:
> I wouldn't interpret it like that.
>
> Calling next() on an empty iterator raises StopIteration. That's not a
> bug indicating a failure, it's the protocol working as expected. Your
> response to that may be to catch the StopIteration and i
On Wed, Nov 26, 2014 at 4:45 AM, Isaac Schwabacher
wrote:
> Yield can also raise StopIteration, if it's thrown in. The current
> interaction of generator.throw(StopIteration) with yield from can't be
> emulated under the PEP's behavior, though it's not clear that that's a
> problem.
>
Hrm. I h
On Wed, Nov 26, 2014 at 11:58 AM, Greg wrote:
> The Abstract claims that the proposal will "unify the behaviour of
> list comprehensions and generator expressions", but it doesn't do
> that.
I don't know that it completely unifies the behaviours, but it does
merge them on the specific situation o
On Wed, Nov 26, 2014 at 10:24 PM, Nick Coghlan wrote:
> The other key aspect is that it changes the answer to the question
> "How do I gracefully terminate a generator function?". The existing
> behaviour has an "or" in the answer: "return from the generator frame,
> OR raise StopIteration from th
On Thu, Nov 27, 2014 at 2:55 AM, Hrvoje Niksic wrote:
> To retrieve a single value from an iterator, one can use the for/break/else
> idiom:
>
> def my_generator():
> ...
> for val in it:
> yield val
> break
> else:
> return
> ...
While that does work, it's
On Thu, Nov 27, 2014 at 9:53 AM, Nick Coghlan wrote:
> The implicit stop decorator would then check the flags on the code object
> attached to the passed in function. If GENERATOR wasn't set, that would be
> an immediate ValueError, while if EXPLICIT_STOP wasn't set, the generator
> function would
On Thu, Nov 27, 2014 at 11:33 AM, Guido van Rossum wrote:
> The design just copies the code object with one flag set differently. Code
> objects are immutable but they can be copied (though the interface to do
> that is kind of hidden).
Yes, but the proposal as written spoke of replacing the gene
On Thu, Nov 27, 2014 at 11:50 AM, Guido van Rossum wrote:
> No, that was a figure of speech. The proposed decorator returns a new
> function object that references a new code object. The original function and
> code object are unchanged.
Then it has a potentially-confusing interaction with decora
On Thu, Nov 27, 2014 at 12:01 PM, Guido van Rossum wrote:
> Well, that's just a general problem with decorator ordering.
Indeed. I was hoping it could be avoided in this instance by just
altering __code__ on an existing function, but if that's not possible,
we fall back to what is, after all, a k
On Thu, Nov 27, 2014 at 12:11 PM, Guido van Rossum wrote:
> A decorator with a side effect *elsewhere* (like the route registrations) is
> acceptable; one with a side effect *on the decorated function* is
> questionable, and instead the decorator should behave "functionally", i.e.
> return a new o
On Thu, Nov 27, 2014 at 8:57 AM, Isaac Schwabacher
wrote:
>> Can you summarize that in a self-contained form for inclusion in the PEP?
>>
>> (That was a rhetorical question. :-)
>
> Sure. Is it on GitHub? ;D
Thanks Isaac, I've incorporated your edits.
https://raw.githubusercontent.com/Rosuav/Gen
On Fri, Nov 28, 2014 at 8:54 AM, Victor Stinner
wrote:
> def return_value(value):
> if 0:
> yield
> raise Return(value)
This is one known significant backward-incompatibility issue with this
PEP - it'll be difficult to make this work on Python 2.7, where
"return value" would be a
On Fri, Nov 28, 2014 at 8:18 PM, Victor Stinner
wrote:
> 2014-11-28 10:12 GMT+01:00 Greg Ewing :
>> I don't understand. If I'm interpreting PEP 479 correctly, in
>> 'x = yield from foo', a StopIteration raised by foo.__next__()
>> doesn't get turned into a RuntimeError
>
> The Trollius coroutine u
On Sat, Nov 29, 2014 at 12:59 PM, Nathaniel Smith wrote:
> Option 4: Add a new function sys.swap_module_internals, which takes
> two module objects and swaps their __dict__ and other attributes. By
> making the operation a swap instead of an assignment, we avoid the
> lifecycle pitfalls from Optio
On Sun, Nov 30, 2014 at 11:37 AM, Donald Stufft wrote:
> I also don’t know how to do this. When I’m doing multiple things for CPython
> my “branching” strategy is essentially using hg diff to create a patch file
> with my “branch” name (``hg diff > my-branch.patch``), then revert all of my
> chang
On Sun, Nov 30, 2014 at 1:04 PM, Jim J. Jewett wrote:
> I have a strong suspicion that I'm missing something; I have been
> persuaded both directions too often to believe I have a grip on the
> real issue.
>
> So I'm putting out some assumptions; please tell me if I'm wrong, and
> maybe make them
On Sun, Nov 30, 2014 at 4:06 PM, Ben Finney wrote:
> I don't get a vote. So I'm glad there are some within the Python core
> development team that can see the mistakes inherent in depending on
> non-free tools for developing free software.
While this is a laudable view, this kind of extreme stanc
On Sun, Nov 30, 2014 at 8:54 PM, Nick Coghlan wrote:
> On 30 November 2014 at 15:23, Chris Angelico wrote:
>> Python is already using quite a bit of non-free software in its
>> ecosystem. The Windows builds of CPython are made with Microsoft's
>> compiler, and t
On Mon, Dec 1, 2014 at 6:28 AM, Ethan Furman wrote:
> My issues with GitHub range from selfish to philosophical:
>
> - (selfish) I don't want to learn git
This ties in directly with the popularity argument. How many people
are there who know hg and don't know git? How many who know git and
don'
On Sun, Nov 30, 2014 at 7:07 PM, balaji marisetti
wrote:
> Hi,
Hi. This list is for the development *of* Python, not development
*with* Python, so I'm sending this reply also to
python-l...@python.org where it can be better handled. You'll probably
want to subscribe here:
https://mail.python.org
In response to Guido's call for volunteers, I'm offering myself as a
PEP editor. Who is in charge of this kind of thing? Who manages public
key lists etc?
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
On Sat, Dec 13, 2014 at 4:29 PM, Donald Stufft wrote:
> So that's basically it, lowest common demoniator programming where it's hard
> to
> look at the future and see anything but the same (or similar) language subset
> that I'm currently using. This is especially frustrating when you see other
>
On Sat, Dec 13, 2014 at 5:13 PM, Donald Stufft wrote:
> First of all, it's essentially the route that Python itself took and the side
> effects of that is essentially what is making things less-fun for me to write
> Python. Doing the same to the users of the things I write would make me feel
> bad
On Fri, Dec 19, 2014 at 5:39 AM, Guido van Rossum wrote:
>-- Forwarded message --
> From: Victor Stinner
>
> Hi,
>
> Yes, the link is dead. It looks like the following link contains the same
> info:
> https://docs.python.org/devguide/triaging.html
>
> Dead page:
> https://web.arch
On Fri, Dec 19, 2014 at 12:24 PM, Terry Reedy wrote:
> PEP 3 is listed in PEP 0 under Abandoned, Withdrawn, and Rejected PEPs
> If this is proper, it does not make sense to update it.
> If this is not, the header should be updated.
Guido passed the request on to the pep-editors list, which I too
On Thu, Dec 25, 2014 at 2:56 PM, Sky Kok wrote:
> Anyway, sometimes when people review my patches for CPython, they send
> me a notice through Rietveld Code Review Tool which later will send an
> email to me. However, my GMail spam filter is aggressive so the email
> will always be classified as s
On Thu, Jan 1, 2015 at 12:24 PM, Benjamin Peterson wrote:
> On Wed, Dec 31, 2014, at 19:32, Ryan Gonzalez wrote:
>> Not sure if this is something to post here...but...
>>
>> [image: Inline image 1]
>
> That must be some sort of inconsistency in Google's index, since the
> actual page's title is co
On Sun, Jan 4, 2015 at 10:34 AM, Steve Dower wrote:
> http://stevedower.id.au/blog/the-python-3-5-installer/
You talk of installing by default into Program Files, and having a
separate per-user installation mode. How do these two installation
targets interact? Suppose someone installs 3.5 globall
On Mon, Jan 5, 2015 at 9:56 AM, Steve Dower wrote:
> (Windows will always put per-user PATH entries at the end). The py.exe
> launcher handles this best, and the system version will always be found first.
>
> As for versions, 3.5 vs 3.6 should be distinguished explicitly ("py -3.5" vs
> "py -3.6
On Mon, Jan 5, 2015 at 12:20 PM, Steve Dower wrote:
> Unfortunately, Windows enforces the PATH ordering. It constructs the PATH
> from two registry keys, one is the system-wide value (that requires
> administrative privileges to modify) and it is followed by the user's value
> (that does not re
1 - 100 of 1000 matches
Mail list logo
