Re: [Python-Dev] Semi-official read-only Github mirror of the CPython Mercurial repository

n more frequent. Hopefully this will not overrun my bandwidth allocation :) The CPython mirror (https://github.com/python/cpython) has been pretty popular so far, with over 70 forks. Eli On Mon, Sep 30, 2013 at 6:09 AM, Eli Bendersky wrote: > Hi all, > > https://github.com/python/cpyth

Re: [Python-Dev] Semi-official read-only Github mirror of the CPython Mercurial repository

wants to run this, I have no objections to that either. It's using the hg-fast-export tool, though, so its whole cache is required (incremental updates are done and it has its own hg hash -> git hash mapping). Eli > On Sat, Jul 12, 2014, at 09:15, Eli Bendersky wrote: > > Jus

Re: [Python-Dev] https://docs.python.org/3/using/index.html not linking correctly

On Mon, Oct 20, 2014 at 1:01 PM, Terry Reedy wrote: > If I go to https://docs.python.org/3/using/index.html and click on any of > the TOC entries, I get 'connecting' indefinitely. This problem seems > unique to this file. I tried several other index files and clicking am > entry brings up the co

Re: [Python-Dev] (no subject)

On Tue, Feb 10, 2015 at 1:33 AM, Paul Moore wrote: > On 10 February 2015 at 00:29, Neil Girdhar wrote: > >> > function(**kw_arguments, **more_arguments) > >> If the key "key1" is in both dictionaries, more_arguments wins, right? > > > > > > There was some debate and it was decided that duplicate

Re: [Python-Dev] The pysandbox project is broken

On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon wrote: > > > > On Wed, Nov 13, 2013 at 6:30 AM, Facundo Batista > wrote: > >> On Wed, Nov 13, 2013 at 4:37 AM, Maciej Fijalkowski >> wrote: >> >> >> Do you think it would be productive to create an independent Python >> >> compiler, designed with sa

Re: [Python-Dev] The pysandbox project is broken

On Wed, Nov 13, 2013 at 10:27 AM, Brett Cannon wrote: > > > > On Wed, Nov 13, 2013 at 1:05 PM, Eli Bendersky wrote: > >> >> >> >> On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon wrote: >> >>> >>> >>> >>> On We

Re: [Python-Dev] The pysandbox project is broken

On Wed, Nov 13, 2013 at 2:48 PM, Christian Heimes wrote: > Am 13.11.2013 23:37, schrieb Eli Bendersky: > > Yeah, it definitely could. There are two problems currently: 1) the > > patches are for 2.7.x and 2) they have some ugly hacks in them. But I > > will talk to the guy w

Re: [Python-Dev] The pysandbox project is broken

On Wed, Nov 13, 2013 at 10:27 AM, Brett Cannon wrote: > > > > On Wed, Nov 13, 2013 at 1:05 PM, Eli Bendersky wrote: > >> >> >> >> On Wed, Nov 13, 2013 at 6:58 AM, Brett Cannon wrote: >> >>> >>> >>> >>> On We

Re: [Python-Dev] Mixed up core/module source file locations in CPython

On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: > > > > On Sat, Nov 16, 2013 at 1:40 PM, Eric Snow wrote: > >> If you look at the Python and Modules directories in the cpython repo, >> you'll find modules in Python/ and core files (like python.c and >> main.c) in Modules/. (It's like parkin

Re: [Python-Dev] Mixed up core/module source file locations in CPython

On Sun, Nov 17, 2013 at 6:20 AM, Brett Cannon wrote: > > On Nov 17, 2013 8:58 AM, "Eli Bendersky" wrote: > > > > > > > > > > On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: > >> > >> > >> > >> > >>

Re: [Python-Dev] Mixed up core/module source file locations in CPython

On Sun, Nov 17, 2013 at 6:20 AM, Brett Cannon wrote: > > On Nov 17, 2013 8:58 AM, "Eli Bendersky" wrote: > > > > > > > > > > On Sat, Nov 16, 2013 at 3:44 PM, Brett Cannon wrote: > >> > >> > >> > >> > >>

Re: [Python-Dev] Assign(expr* targets, expr value) - why targetS?

On Fri, Nov 22, 2013 at 3:21 AM, anatoly techtonik wrote: > On Fri, Nov 15, 2013 at 5:43 PM, Benjamin Peterson > wrote: > > 2013/11/15 anatoly techtonik : > >> On Tue, Nov 12, 2013 at 5:08 PM, Benjamin Peterson > wrote: > >>> 2013/11/12 anatoly techtonik : > On Sun, Nov 10, 2013 at 8:34 AM,

Re: [Python-Dev] buildbot's are needlessly compiling -O0

On Sun, Nov 24, 2013 at 6:12 AM, anatoly techtonik wrote: > On Sun, Nov 24, 2013 at 12:43 PM, Nick Coghlan wrote: > > > > On 24 Nov 2013 17:15, "Gregory P. Smith" wrote: > >> > >> our buildbots are setup to configure --with-pydebug which also > >> unfortunately causes them to compile with -O0...

[Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

Hello, argparse does prefix matching as long as there are no conflicts. For example: argparser = argparse.ArgumentParser() argparser.add_argument('--sync-foo', action='store_true') args = argparser.parse_args() If I pass "--sync" to this script, it recognizes it as "--sync-foo". This behavior is

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

at on exactly the use case parse_known_args was designed for: whenever I have a Python script using argparse and passing unknown arguments to other programs, I have to manually make sure there are no common prefixes between any commands to avoid this problem. Frankly I don't see how the current

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

On Tue, Nov 26, 2013 at 9:46 AM, R. David Murray wrote: > On Tue, 26 Nov 2013 09:30:10 -0800, Eli Bendersky > wrote: > > Hello, > > > > argparse does prefix matching as long as there are no conflicts. For > > example: > > > > argparser = argparse.A

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

ouch upon it. > > As to why parse_known_args also does this, I can see the reasoning behind > this behavior: to the end user, "--sync" is a valid option, so it would be > surprising if it didn't get recognized under certain conditions. > > I suppose you were badly bitten

Re: [Python-Dev] potential argparse problem: bad mix of parse_known_args and prefix matching

On Tue, Nov 26, 2013 at 9:30 AM, Eli Bendersky wrote: > Hello, > > argparse does prefix matching as long as there are no conflicts. For > example: > > argparser = argparse.ArgumentParser() > argparser.add_argument('--sync-foo', action='store_true') >

[Python-Dev] Fwd: 2.x vs 3.x survey results

-- Forwarded message -- From: Antoine Pitrou Date: Sun, Jan 5, 2014 at 9:32 AM Subject: Re: [Python-Dev] 2.x vs 3.x survey results To: [email protected] On Sun, 5 Jan 2014 11:23:45 -0600 Brian Curtin wrote: > On Sun, Jan 5, 2014 at 3:08 AM, Lennart Regebro wrote: > > On Sun

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 21, 2014 at 6:28 AM, Nick Coghlan wrote: > On 22 February 2014 00:03, Eli Bendersky wrote: > > On Thu, Feb 20, 2014 at 7:15 PM, Chris Angelico > wrote: > >> > >> PEP: 463 > >> Title: Exception-catching expressions > >> Version: $

Re: [Python-Dev] PEP 463: Exception-catching expressions

On Fri, Feb 21, 2014 at 6:46 AM, Nick Coghlan wrote: > On 22 February 2014 00:37, Eli Bendersky wrote: > > This goes against anything I understand about how exceptions should and > > should not be used. > > I think you're thinking of a language that isn't P

Re: [Python-Dev] Confirming status of new modules in 3.4

On Fri, Mar 14, 2014 at 4:56 PM, Giampaolo Rodola' wrote: > > On Fri, Mar 14, 2014 at 9:25 PM, R. David Murray wrote: > >> Not Provisional: >> >> selectors >> > > Wouldn't it be wiser to consider this one provisional as well? > +1 because of the intimate ties to asyncio Eli > > > > -- > Giam

Re: [Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson wrote: > > > On Wed, Mar 26, 2014, at 14:25, Barry Warsaw wrote: > > On Mar 26, 2014, at 01:55 PM, Benjamin Peterson wrote: > > > > >It's not a bad idea. (I believe others have proposed an red-black tree.) > > >Certainly, it requires a PEP and a f

Re: [Python-Dev] Language Summit notes

On Thu, Apr 10, 2014 at 12:30 PM, Antoine Pitrou wrote: > Le 10/04/2014 20:58, Guido van Rossum a écrit : > > >> Huh, I totally missed this (and I just gave Kushal a confused answer >> when he asked me about it in person). Can someone please post here what >> the plan is exactly? I don't want to p

Re: [Python-Dev] devguide: Add myself to developer log and as a Windows expert.

On Sun, May 11, 2014 at 6:57 AM, Steve Dower wrote: > Thanks. > > For those who missed the earlier discussions, Martin v. Löwis has handed > over responsibility for the Windows installers. It sounds like Brett Cannon > and I are both in a position to build 2.7 right now, and I hope to simplify >

Re: [Python-Dev] Download Counts (was: Language Summit notes)

On Wed, May 28, 2014 at 11:10 AM, Guido van Rossum wrote: > Is the Windows/Mac ratio still 70/30, with Linux in the single digits? > > Most Linux installs go through package managers which don't count here, no? Eli > > On Wed, May 28, 2014 at 10:57 AM, Brian Curtin wrote: > >> On May 28, 2014

Re: [Python-Dev] Moving Python 3.5 on Windows to a new compiler

On Fri, Jun 6, 2014 at 4:32 PM, Sturla Molden wrote: > Brian Curtin wrote: > > > Well we're certainly not going to assume such a thing. I know people do > > that, but many don't (I never have). > > If Python 2.7 users are left with a dead compiler on Windows, they will > find a solution. For exa

Re: [Python-Dev] cpython and python debugger documentation

On Mon, Jun 9, 2014 at 7:50 AM, Paul Sokolovsky wrote: > Hello, > > On Mon, 09 Jun 2014 14:01:18 + > Brett Cannon wrote: > > > On Sat Jun 07 2014 at 5:55:29 PM, Le Pa wrote: > > > > > Hi, > > > > > > I am interested in learning how the cpython interpreter is designed > > > and implemented,

Re: [Python-Dev] Built with VS2012 Express for desktop

On Tue, Feb 19, 2013 at 10:50 AM, Oleg Broytman wrote: > Hello. > >This mailing list is to work on developing Python (adding new > features to Python itself and fixing bugs); if you're having problems > learning, understanding or using Python, please find another forum. > Probably python-list

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Thu, Feb 21, 2013 at 9:23 AM, Stephen J. Turnbull wrote: > Jesse Noller writes: > > > I guess someone need to write a proof of concept exploit for you > > and release it into the wild. > > This is a bit ridiculous. This stuff looks easy enough that surely > Christian's post informed any mali

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Thu, Feb 21, 2013 at 11:12 AM, Christian Heimes wrote: > Am 21.02.2013 19:39, schrieb Eli Bendersky: > > Just to clarify for my own curiosity. These attacks (e.g. > > http://en.wikipedia.org/wiki/Billion_laughs) have been known and public > > since 2003? &

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Sat, Feb 23, 2013 at 7:57 AM, R. David Murray wrote: > On Sun, 24 Feb 2013 01:31:09 +1000, Nick Coghlan > wrote: > > On Sun, Feb 24, 2013 at 1:06 AM, Antoine Pitrou > wrote: > > > On Sat, 23 Feb 2013 16:02:31 +0100 > > > Stefan Krah wrote: > > >> eli.bendersky wrote: > > >> > +Ordered compa

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Sat, Feb 23, 2013 at 9:04 AM, Antoine Pitrou wrote: > On Sat, 23 Feb 2013 08:27:50 -0800 > Eli Bendersky wrote: > > > See also http://bugs.python.org/issue16801#msg178542 for another use > > > case for named values. > > > > > > I've seen an

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

> 2) When you do, wrapping the item in int() doesn't seem too bad to me. >> > > If it was just once or twice, sure, but I use them as names for ints, > which means I use them as ints, which means I would have a boat load of > int() calls. > Personally I don't see "name for ints" as being the main

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Mon, Feb 25, 2013 at 8:56 AM, Antoine Pitrou wrote: > Le Mon, 25 Feb 2013 10:44:33 -0600, > Skip Montanaro a écrit : > > > Besides "we just don't need them int-based in these use-cases" what > > > are the reasons for the strong desire to have them be valueless? > > > > Not sure about other pe

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Mon, Feb 25, 2013 at 3:17 PM, Glyph wrote: > > On Feb 25, 2013, at 12:32 PM, Barry Warsaw wrote: > > Dumb question, but are flufl.enums ordered? That's also an important use > case. > > > Kind of. Ordered comparisons are explicitly not supported, but iteration > over > the Enum is guarantee

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On Tue, Feb 26, 2013 at 12:30 AM, Stefan Krah wrote: > Larry Hastings wrote: > > http://bugs.python.org/issue16612 > > > > I'm guessing python-dev is the right place for the ten-thousand-foot view > > topics: the merits of the specific proposed DSL syntax, the possible > runtime > > extensio

Re: [Python-Dev] Announcing PEP 436: The Argument Clinic DSL

On Mon, Feb 25, 2013 at 4:11 PM, Larry Hastings wrote: > > Following up on a conversation on python-dev from last December: > > http://mail.python.org/pipermail/python-dev/2012-December/122920.html > > I'm pleased to announced PEP 436, proposing Argument Clinic for adoption > into the CPython sou

Re: [Python-Dev] cffi in stdlib

On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan wrote: > On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski > wrote: > > Hello. > > > > I would like to discuss on the language summit a potential inclusion > > of cffi[1] into stdlib. > > I think cffi is well worth considering as a possible inclusi

Re: [Python-Dev] cffi in stdlib

On Tue, Feb 26, 2013 at 8:26 AM, Maciej Fijalkowski wrote: > On Tue, Feb 26, 2013 at 5:42 PM, Nick Coghlan wrote: > > On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski > wrote: > >> Hello. > >> > >> I would like to discuss on the language summit a potential inclusion > >> of cffi[1] into stdli

Re: [Python-Dev] cffi in stdlib

On Tue, Feb 26, 2013 at 8:39 AM, Maciej Fijalkowski wrote: > On Tue, Feb 26, 2013 at 6:34 PM, Eli Bendersky wrote: > > > > On Tue, Feb 26, 2013 at 7:42 AM, Nick Coghlan > wrote: > >> > >> On Wed, Feb 27, 2013 at 1:13 AM, Maciej Fijalkowski > >> wr

Re: [Python-Dev] cffi in stdlib

* Work either at the level of the ABI (Application Binary Interface) > or the API (Application Programming Interface). Usually, C libraries > have a specified C API but often not an ABI (e.g. they may document a > “struct” as having at least these fields, but maybe more). (ctypes > works at the AB

Re: [Python-Dev] cffi in stdlib

On Tue, Feb 26, 2013 at 11:29 PM, Ronald Oussoren wrote: > > On 26 Feb, 2013, at 16:13, Maciej Fijalkowski wrote: > > > Hello. > > > > I would like to discuss on the language summit a potential inclusion > > of cffi[1] into stdlib. > > The API in general looks nice, but I do have some concens w.r

Re: [Python-Dev] cffi in stdlib

> > I read the cffi docs once again and went through some of the examples. I > > want to divide this to two topics. > > > > One is what you call the "ABI" level. IMHO, it's hands down superior to > > ctypes. Your readdir demo demonstrates this very nicely. I would > definitely > > want to see this

[Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

[Splitting into a separate thread] Do we really need to overthink something that requires a trivial alias to set up for one's own convenience? Picking a Python version (as Barry mentions) is just one of the problems. What's wrong with: alias rupytests='python3 -m unittest discover" alias runpyte

Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

On Mon, Mar 4, 2013 at 1:28 PM, Antoine Pitrou wrote: > On Mon, 4 Mar 2013 13:26:57 -0800 > Eli Bendersky wrote: > > [Splitting into a separate thread] > > > > Do we really need to overthink something that requires a trivial alias to > > set up for one's

Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw wrote: > On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: > > >The big thing is automated tools, not developers. > > Exactly. > I don't understand. Is "python -m unittest discover" too much typing for automatic tools? If anything, it's much more po

Re: [Python-Dev] built-in Python test runner (was: Python Language Summit at PyCon: Agenda)

On Mon, Mar 4, 2013 at 4:09 PM, Robert Collins wrote: > On 5 March 2013 12:49, Eli Bendersky wrote: > > > > On Mon, Mar 4, 2013 at 2:14 PM, Barry Warsaw wrote: > >> > >> On Mar 05, 2013, at 11:01 AM, Robert Collins wrote: > >> > >>

Re: [Python-Dev] [docs] undocumented argtypes magic in ctypes?

, DIRENT is certainly not convertible to DIRENT_p Eli > > On Tue, Mar 5, 2013 at 4:26 PM, Eli Bendersky wrote: > > Hello, > > > > While playing with ctypes a bit, I noticed a feature that doesn't appear > to > > be documented. Suppose I import the readdir_r functi

Re: [Python-Dev] [docs] undocumented argtypes magic in ctypes?

On Thu, Mar 7, 2013 at 3:37 AM, Thomas Heller wrote: > Am 06.03.2013 18:19, schrieb Eli Bendersky: > >> >> >> >> On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov > <mailto:andrew.svetlov@gmail.**com >> wrote: >> >> Looks like bug for me

Re: [Python-Dev] [docs] undocumented argtypes magic in ctypes?

On Thu, Mar 7, 2013 at 5:53 AM, Thomas Heller wrote: > ctypes seems to auto-convert arguments when argtypes is >> specified. This >> fact is documented. However, I'm not sure whether this >> auto-conversion >> is advanced enough to apply byref. Because othe

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On Thu, Mar 14, 2013 at 6:33 PM, Terry Reedy wrote: > The timeit doc describes four public attributes. > The current timeit.__all__ only lists one. > http://bugs.python.org/**issue17414 > proposes to expand __all__ to include all four: > -__all__ = ["Timer"] >

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

; time, and we never give a second thought to users of import *. :-) > > Oh yes, I agree there should be no problem in the default branch. My comment was mainly aimed at backporting it; I should've made it clearer. Eli > On Thu, Mar 14, 2013 at 6:54 PM, Eli Bendersky wrote: > &

Re: [Python-Dev] Status of XML fixes

I like to give an update on the XML vulnerability fixes. Brett has asked > me a couple of days ago but I haven't had time to answer. I was/am busy > with my daily job. > > Any attempt to fix the XML issues *will* change the behavior of the > library and result into an incompatibility with older re

Re: [Python-Dev] Status of XML fixes

On Sun, Mar 17, 2013 at 12:00 PM, Stefan Behnel wrote: > Eli Bendersky, 17.03.2013 19:25: > > IMHO Benjamin is right, given that this attack has been known to exist > > since 2003. Moreover, as it appears that no changes whatsoever are going > to > > make it into 2.7, I d

Re: [Python-Dev] [Python-checkins] cpython: Issue #13248: removed deprecated and undocumented difflib.isbjunk, isbpopular.

A mention in Misc/NEWS can't hurt here, Terry. Even though it's undocumented, some old code could rely on it being there and this code will break with the transition to 3.4 Eli On Tue, Mar 19, 2013 at 4:44 PM, terry.reedy wrote: > http://hg.python.org/cpython/rev/612d8bbcfa3a > changeset: 828

[Python-Dev] IDLE in the stdlib

Interesting writeup about PyCon 2013 young coder education: http://therealkatie.net/blog/2013/mar/19/pycon-2013-young-coders/ Quote: "We used IDLE because it's already on Raspian's desktop. Personally, I like IDLE as a teaching tool. It's included in the standard library, it does tab completion a

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 10:11 AM, Todd Rovito wrote: > On Wed, Mar 20, 2013 at 12:41 PM, Eli Bendersky wrote: > > Interesting writeup about PyCon 2013 young coder > > education: > http://therealkatie.net/blog/2013/mar/19/pycon-2013-young-coders/ > > > > Quote: >

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 11:09 AM, R. David Murray wrote: > On Wed, 20 Mar 2013 09:41:53 -0700, Eli Bendersky > wrote: > > Personally, I think that IDLE reflects badly on Python in more ways than > > one. It's badly maintained, quirky and ugly. It serves a very narrow set

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 12:14 PM, Benjamin Peterson wrote: > 2013/3/20 Barry Warsaw : > > On Mar 20, 2013, at 11:22 AM, Eli Bendersky wrote: > > > >>IDLE would be a great first foray into this "separate project" world, > >>because it is many ways a sepa

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 12:51 PM, Xavier Morel wrote: > On 2013-03-20, at 20:38 , Barry Warsaw wrote: > > > On Mar 20, 2013, at 12:31 PM, Guido van Rossum wrote: > > > >> Agreed that the "sync into stdlib" think should not happen, or should at > >> best be a temporary measure until we can remove i

Re: [Python-Dev] IDLE in the stdlib

>> Agreed that the "sync into stdlib" think should not happen, or should at > >> best be a temporary measure until we can remove idle from the source > >> tarball (maybe at the 3.4 release, otherwise at 3.5). > > > > Right. Ultimately, I think IDLE should be a separate project entirely, > but I

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 1:59 PM, Xavier Morel wrote: > > On 2013-03-20, at 21:14 , Eli Bendersky wrote: > > >>> Agreed that the "sync into stdlib" think should not happen, or should > at > > > >>>> best be a temporary measure until we can r

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 7:57 PM, Raymond Hettinger < [email protected]> wrote: > > > On Mar 20, 2013, at 12:38 PM, Barry Warsaw wrote: > > Right. Ultimately, I think IDLE should be a separate project entirely, > but I > guess there's push back against that too. > > > The most important

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy wrote: > On 3/20/2013 12:41 PM, Eli Bendersky wrote: > > Personally, I think that IDLE reflects badly on Python in more ways than >> one. It's badly maintained, quirky and ugly. >> > > Ugly is subjective: by wh

Re: [Python-Dev] IDLE in the stdlib

> > On Mar 20, 2013, at 12:38 PM, Barry Warsaw > > wrote: > > > >> Right. Ultimately, I think IDLE should be a separate project > entirely, but I > >> guess there's push back against that too. > > > > The most important feature of IDLE is that it ships

Re: [Python-Dev] IDLE in the stdlib

On Wed, Mar 20, 2013 at 11:42 PM, Terry Reedy wrote: > On 3/20/2013 11:54 PM, Eli Bendersky wrote: > >> On Wed, Mar 20, 2013 at 8:32 PM, Terry Reedy > > > Ugly is subjective: by what standard and compared to what? >> >> Compared to other existing Python IDE

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo

On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov wrote: > http://hg.python.org/cpython/rev/6cf485ffd325 > changeset: 83110:6cf485ffd325 > parent: 83106:94fb906e5899 > parent: 83109:9610ede72ed2 > user:Andrew Svetlov > date:Fri Apr 05 11:40:01 2013 +0300 > summary: > Fi

Re: [Python-Dev] [Python-checkins] cpython (merge 3.3 -> default): Fix typo

M, Andrew Svetlov wrote: > Do you mean something like: > «Let's also change the rest of the program to make the new functionality:» > ??? > > > On Sat, Apr 6, 2013 at 6:41 AM, Eli Bendersky wrote: > > > > On Fri, Apr 5, 2013 at 1:40 AM, andrew.svetlov < >

[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

rry Warsaw , Eli Bendersky Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2013-02-23 Python-Version: 3.4 Post-History: 2013-02-23 Abstract This PEP proposes adding an enumeration type to the Python standard library. Specifically, it proposes moving th

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Fri, Apr 12, 2013 at 1:52 PM, R. David Murray wrote: > On Fri, 12 Apr 2013 15:33:02 -0400, Barry Warsaw wrote: > > On Apr 12, 2013, at 11:21 AM, Russell E. Owen wrote: > > > > >I, too, would strongly prefer to see ordering within an enum. I use > > >home-made enums heavily in my code and find

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Fri, Apr 12, 2013 at 2:17 PM, R. David Murray wrote: > On Fri, 12 Apr 2013 14:06:55 -0700, Eli Bendersky > wrote: > > I actually think that having values with different types within a single > > Enum is conceptually wrong and should be disallowed at creation time. > With

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Fri, Apr 12, 2013 at 3:23 PM, Barry Warsaw wrote: > On Apr 12, 2013, at 12:56 PM, Guido van Rossum wrote: > > >Agreed. I can't easily find that in the PEP though. It doesn't mention > >__getitem__ and I can't find any examples of using []. > > Indeed, this looks like an omission in the PEP. f

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Sat, Apr 13, 2013 at 1:31 AM, Serhiy Storchaka wrote: > On 12.04.13 15:55, Eli Bendersky wrote: > >> The enumeration value names are available through the class members:: >> >> >>> for member in Colors.__members__: >> ... print(member)

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Sat, Apr 13, 2013 at 6:43 AM, Lennart Regebro wrote: > OK, so I finally got tie to read the PEP. I like it, I really have > missed Enums, this is awesome. > > That's all folks! > > //Lennart > More of these kinds of comments ;-) Thanks, Lennart. __

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #16447: Fix potential segfault when setting __name__ on a class.

Test case? On Sat, Apr 13, 2013 at 7:19 AM, mark.dickinson wrote: > http://hg.python.org/cpython/rev/d5e5017309b1 > changeset: 83283:d5e5017309b1 > branch: 2.7 > user:Mark Dickinson > date:Sat Apr 13 15:19:05 2013 +0100 > summary: > Issue #16447: Fix potential segfault

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #16447: Fix potential segfault when setting __name__ on a class.

On Sat, Apr 13, 2013 at 7:25 AM, Eli Bendersky wrote: > Test case? > > Ugh, sorry. I missed it. Ignore my previous email please. Eli > > On Sat, Apr 13, 2013 at 7:19 AM, mark.dickinson < > [email protected]> wrote: > >> http://hg.python.org/cpyt

Re: [Python-Dev] Sharing docstrings between the Python and C implementations of a module

On Mon, Apr 15, 2013 at 3:45 AM, Nick Coghlan wrote: > On Mon, Apr 15, 2013 at 8:17 PM, Maciej Fijalkowski > wrote: > > On Mon, Apr 15, 2013 at 9:56 AM, David Lam > wrote: > >> I tried to find an example in the source which addressed this, but > >> found that the docstrings in similar cases to

Re: [Python-Dev] cpython: Simplify the code of get_attrib_from_keywords somewhat.

On Mon, Apr 22, 2013 at 10:13 AM, Serhiy Storchaka wrote: > On 22.04.13 15:52, eli.bendersky wrote: > >> http://hg.python.org/cpython/**rev/c9674421d78e<http://hg.python.org/cpython/rev/c9674421d78e> >> changeset: 83494:c9674421d78e >> user:Eli Bendersky

Re: [Python-Dev] slow hg clone of python repo?

On Wed, Apr 24, 2013 at 4:37 PM, Sean Felipe Wolfe wrote: > On Wed, Apr 24, 2013 at 4:24 PM, Guido van Rossum > wrote: > > It's a big repo. Patience. > > > > On Wed, Apr 24, 2013 at 4:17 PM, Sean Felipe Wolfe > wrote: > >> Hey everybody, I'm trying to download the python sources with hg and > >>

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 2:42 AM, Antoine Pitrou wrote: > Le Fri, 12 Apr 2013 05:55:00 -0700, > Eli Bendersky a écrit : > > > > To programmatically access enumeration values, use ``getattr``:: > > > > >>> getattr(Colors, 'red') > >

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 5:29 AM, Antoine Pitrou wrote: > Le Thu, 25 Apr 2013 05:21:50 -0700, > Eli Bendersky a écrit : > > > > > > > or: > > > > > > >>> Colors(1) > > > > > > > > > > > This syntax w

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman wrote: > On 04/25/2013 06:03 AM, Eli Bendersky wrote: > >> >> The __call__ syntax has been repurposed for the convenience API: >> >> --> Animals = Enum('Animals', 'ant bee ca

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 9:39 AM, Ethan Furman wrote: > On 04/25/2013 09:34 AM, Eli Bendersky wrote: > > >> >> >> On Thu, Apr 25, 2013 at 8:46 AM, Ethan Furman > [email protected]>> wrote: >> >> On 04/25/2013 06:03 AM, Eli Bendersky wrot

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Thu, Apr 25, 2013 at 2:17 PM, Barry Warsaw wrote: > On Apr 25, 2013, at 01:18 PM, Ethan Furman wrote: > > >> Ignore the single argument call syntax for Enums please. As Eli pointed > >> out, you have getitem syntax for this and the single argument call > syntax > >> is deprecated. It will be

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum wrote: > On Fri, Apr 26, 2013 at 10:33 AM, Glenn Linderman > wrote: > > On 4/25/2013 9:19 PM, Guido van Rossum wrote: > > > > On Thu, Apr 25, 2013 at 8:39 PM, Glenn Linderman > > wrote: > > > > an enumeration of objects whose class defines __ca

Re: [Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

On Fri, Apr 26, 2013 at 2:41 PM, Guido van Rossum wrote: > On Fri, Apr 26, 2013 at 11:17 AM, Eli Bendersky wrote: > > On Fri, Apr 26, 2013 at 10:36 AM, Guido van Rossum > wrote: > >> > On 4/25/2013 9:19 PM, Guido van Rossum wrote: > >> I think you've lost

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sun, Apr 28, 2013 at 12:32 PM, Ethan Furman wrote: > Example enumeration: > > class Seasons(Enum): > SPRING = 1 > SUMMER = 2 > AUTUMN = 3 > WINTER = 4 > > days_in_year = 365 > > @property > def avg_temp(self): > return (75, 92, 66, 33)[int(self)+1] # enums a

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum wrote: > On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote: > > Functions are descriptors, so this rule already covers ordinary methods. > The > > slight concern I have with making the duck typed exclusion only > descriptors > > (rather than de

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Sun, Apr 28, 2013 at 9:09 PM, Guido van Rossum wrote: > On Sun, Apr 28, 2013 at 3:28 PM, Nick Coghlan wrote: > > Functions are descriptors, so this rule already covers ordinary methods. > The > > slight concern I have with making the duck typed exclusion only > descriptors > > (rather than de

Re: [Python-Dev] enum discussion: can someone please summarize open issues?

On Mon, Apr 29, 2013 at 2:45 PM, Terry Jan Reedy wrote: > On 4/29/2013 8:24 AM, Eli Bendersky wrote: > > Thanks for the summary. One issue I don't see addressed here is >> int-compatibility. Am I correct to assume that nothing changes w.r.t. >> that, and that an IntEnu

Re: [Python-Dev] Enumeration item arguments?

On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman wrote: > In the Planet example we saw the possibility of specifying arguments to > enum item __init__: > > class Planet(Enum): > MERCURY = (3.303e+23, 2.4397e6) > VENUS = (4.869e+24, 6.0518e6) > EARTH = (5.976e+24, 6.37814e6) > MAR

Re: [Python-Dev] Enumeration item arguments?

On Mon, Apr 29, 2013 at 7:30 PM, Philip Jenvey wrote: > > On Apr 29, 2013, at 3:25 PM, Eli Bendersky wrote: > > > On Mon, Apr 29, 2013 at 2:59 PM, Ethan Furman > wrote: > > In the Planet example we saw the possibility of specifying arguments to > enum item __init__

Re: [Python-Dev] Enumeration items: mixed types?

On Mon, Apr 29, 2013 at 5:38 PM, Greg Ewing wrote: > Ethan Furman wrote: > >> I suppose the other option is to have `.value` be whatever was assigned >> (1, 'really big country', and (8273.199, 517) ), >> > > I thought that was the intention all along, and that we'd > given up on the idea of auto-

Re: [Python-Dev] PEP-435 reference implementation

On Tue, Apr 30, 2013 at 1:12 PM, Ethan Furman wrote: > Greetings, > > Eli asked me to put the reference implementation here for review. > > It is available at https://bitbucket.org/stoneleaf/aenum in ref435.py and > test_ref435.py > Thanks, Ethan. All - note that strictly speaking this impleme

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 10:48 AM, Guido van Rossum wrote: > On Wed, May 1, 2013 at 10:21 AM, Ethan Furman wrote: > > We may not want to /completely/ disallow subclassing. Consider: > > > > --> class StrEnum(str, Enum): > > ...'''string enums for Business Basic variable names''' > > ... > > -

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > On Wed, 01 May 2013 10:21:30 -0700 > > Ethan Furman wrote: > >> We may not want to /completely/ disallow subclassing. Consider: > >> > >> --> class StrEnum(str, Enum): > >> ...'''string e

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 11:47 AM, Georg Brandl wrote: > Am 01.05.2013 20:04, schrieb Eli Bendersky: > > > Actually, in flufl.enum, IntEnum had to define a magic __value_factory__ > > attribute, but in the current ref435 implementation this isn't needed, so > > I

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou wrote: > On Wed, 1 May 2013 13:05:53 -0700 > Eli Bendersky wrote: > > On Wed, May 1, 2013 at 11:59 AM, Georg Brandl wrote: > > > > > Am 01.05.2013 20:44, schrieb Antoine Pitrou: > > > > On Wed, 01 May 2

Re: [Python-Dev] Enum: subclassing?

On Wed, May 1, 2013 at 1:45 PM, Antoine Pitrou wrote: > On Wed, 1 May 2013 13:43:22 -0700 > Eli Bendersky wrote: > > > On Wed, May 1, 2013 at 1:33 PM, Antoine Pitrou > wrote: > > > > > On Wed, 1 May 2013 13:05:53 -0700 > > > Eli Bendersky wrote: >

  1   2   3   4   5   >