Re: [Python-Dev] PEP 394 request for pronouncement (python2 symlink in *nix systems)

2012-02-16 Thread Barry Warsaw
On Feb 16, 2012, at 09:54 PM, Nick Coghlan wrote: >It turns out I'd forgotten what was in the PEP - the Notes section >already contained a lot of suggestions along those lines. I changed >the title of the section to "Migration Notes", but tried to make it >clear that those *aren't* consensus recom

[Python-Dev] hash randomization in the 2.6 branch

2012-02-20 Thread Barry Warsaw
I've just committed a back port of issue 13703, the hash randomization patch, to the Python 2.6 branch. I have left the forward porting of this to Python 2.7 to Benjamin. test_json will fail with randomization enabled since there is a sort order dependency in the __init__.py doctest. I'm not goi

Re: [Python-Dev] hash randomization in 3.3

2012-02-21 Thread Barry Warsaw
On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote: >2012/2/21 Antoine Pitrou : >> >> Hello, >> >> Shouldn't it be enabled by default in 3.3? Yes. >Should you be able to disable it? No, but you should be able to provide a seed. -Barry ___ Python-D

Re: [Python-Dev] hash randomization in 3.3

2012-02-21 Thread Barry Warsaw
On Feb 21, 2012, at 09:58 PM, Xavier Morel wrote: >On 2012-02-21, at 21:24 , Brett Cannon wrote: >> On Tue, Feb 21, 2012 at 15:05, Barry Warsaw wrote: >> >>> On Feb 21, 2012, at 02:58 PM, Benjamin Peterson wrote: >>> >>>> 2012/2/21 Antoine Pitrou :

Re: [Python-Dev] hash randomization in 3.3

2012-02-22 Thread Barry Warsaw
On Feb 22, 2012, at 09:04 PM, Stephen J. Turnbull wrote: >Brett Cannon writes: > > > I think that's inviting trouble if you can provide the seed. It leads to a > > false sense of security > >I thought the point of providing the seed was for reproducability of >tests and the like? > >As for "false

[Python-Dev] Issue 13703 is closed for the Python 2.6 branch

2012-02-22 Thread Barry Warsaw
Two more small details to address, and then I think we're ready to start creating release candidates. - sys.flags.hash_randomization In the tracker issue, I had previously stated a preference that this flag only reflect the state of the -R command line option, not the $PYTHONHASHSEED en

Re: [Python-Dev] Status regarding Old vs. Advanced String Formating

2012-02-24 Thread Barry Warsaw
On Feb 24, 2012, at 10:39 PM, Martin v. Löwis wrote: >> It is a burden for some people to learn and remember the exact details >> of both systems and exactly how they differ. Having both in the stdlib >> hurts readability for such people. I would prefer that the stdlib only >> used {} formatting o

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-25 Thread Barry Warsaw
On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote: >* Improve datetime.datetime objects so they support nanosecond resolution, > in such a way that it's 100% painless to make them even more precise in > the future. +1 >* Add support to datetime objects that allows adding and subtracting int

Re: [Python-Dev] PEP 414

2012-02-26 Thread Barry Warsaw
This seems like too strong a statement: "Python 2.6 and Python 2.7 support syntax features from Python 3 which for the most part make a unified code base possible. Many thought that the unicode_literals future import might make a common source possible, but it turns out that it's d

Re: [Python-Dev] PEP 414

2012-02-26 Thread Barry Warsaw
On Feb 26, 2012, at 09:20 PM, Nick Coghlan wrote: >It reduces the problem (compared to omitting the import and using a >u() function), but it's still ugly and still involves the "action at a >distance" of the unicode literals import. Frankly, that doesn't bother me at all. I've been using the fu

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-26 Thread Barry Warsaw
On Feb 26, 2012, at 05:44 PM, Brett Cannon wrote: >On Sat, Feb 25, 2012 at 22:13, Guido van Rossum wrote: > >> If this can encourage more projects to support Python 3 (even if it's >> only 3.3 and later) and hence improve adoption of Python 3, I'm all >> for it. >> >> >+1 from me for the same rea

Re: [Python-Dev] Marking packaging-related PEPs as Finished after fixing some bugs in them

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 11:40 AM, Éric Araujo wrote: > They’re all implemented in packaging/distutils2. Sadly, all of them >have rather serious issues, so I wanted to ask what the process should >be to solve the problems and mark the PEPs final. From a process point of view, I'd say you should fix

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 12:34 PM, Giampaolo Rodolà wrote: >Il 25 febbraio 2012 21:23, Armin Ronacher >If the main point of this proposal is avoiding an explicit 2to3 run on >account of 2to3 being too slow then I'm -1. 2to3's speed isn't the only problem with the tool, although it's a big one. It also

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 11:21 AM, Martin v. Löwis wrote: >I find this rationale a bit sad: it's not that there is any (IMO) good >technical reason for the feature - only that people "hate" the many >available alternatives for some reason. It makes me sad too, and as I've said, I personally have no pr

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 03:39 PM, Chris McDonough wrote: >Note that u'' literals are sort of the tip of the iceberg here; >supporting them will obviously not make development under the subset an >order of magnitude less sucky, just a tiny little bit less sucky. There >are other extremely annoying thi

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 09:43 PM, Vinay Sajip wrote: >Well, according to the approach I described above, that one thing needs to be >the present 3.x syntax - 'xxx' is text, b'xxx' is bytes, and f('xxx') is >native string (or whatever name you want instead of f). With the >unicode_literals import, that

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 02:06 PM, Guido van Rossum wrote: >Indeed, the wrangling has gone too far already. I'm accepting the PEP. It's >about as harmless as they come. Make it so. I've learned that once a PEP is pronounced upon, it's usually to my personal (if not all of our mutual :) benefit to stop

Re: [Python-Dev] PEP 414

2012-02-27 Thread Barry Warsaw
On Feb 27, 2012, at 10:38 PM, Armin Ronacher wrote: >Indeed I have three other PEPs in the work. The reintroduction of >"except (((ExceptionType),),)", the "<>" comparision operator and the >removal of "nonlocal", the latter to make Python 2.x developers feel >better about themselves. :-) One of

[Python-Dev] Spreading the Python 3 religion (was Re: PEP 414 - Unicode Literals for Python 3)

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 08:41 AM, R. David Murray wrote: >Hmm. It seems to me that this argument implies that PEP 414 is just >as likely to *slow down* adoption of Python3 as it is to speed it up, >since if this issue is as big a barrier as indicated, many potential >porters may choose to wait until

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 10:49 PM, Nick Coghlan wrote: >On Tue, Feb 28, 2012 at 10:19 PM, Antoine Pitrou wrote: >> Again that's wrong. If you cleverly use 2to3 to port between branches, >> patches only have to be written against the 2.x version. > >Apparently *you* know how to do that, but I don't. If

Re: [Python-Dev] Spreading the Python 3 religion (was Re: PEP 414 - Unicode Literals for Python 3)

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 10:23 AM, Brett Cannon wrote: >Well, when the code is committed I will update the porting HOWTO and push >the __future__ imports first since they cover more versions of Python (i.e. >Python 3.2). But I will mention the options that skip the __future__ >imports for those that ch

Re: [Python-Dev] PEP 414

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 11:29 AM, Yury Selivanov wrote: >Could you please remove from the PEP the following statement: > >"""As it stands, Python 3 is currently a bad choice for long-term >investments, since the ecosystem is not yet properly developed, and >libraries are still fighting with their AP

Re: [Python-Dev] PEP 414 - Unicode Literals for Python 3

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 10:59 AM, Jim J. Jewett wrote: >For many people -- particularly those who haven't ported yet -- 3.x >will mean 3.3+. There are some who will support 3.2 because it is a >LTS release on some distribution, just as there were some who supported >Python 1.5 (but not 1.6) long into

Re: [Python-Dev] Backporting PEP 414

2012-02-28 Thread Barry Warsaw
On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote: >> If there is already a FAQ entry feel free to point me to it, but I would >> still be curious why, in this instance, practicality does not beat purity? > >Because it's practical not to break bugfix releases with new features. And because no

Re: [Python-Dev] PEP 414

2012-02-29 Thread Barry Warsaw
On Feb 29, 2012, at 07:30 AM, Yury Selivanov wrote: >"""As it stands, Python 3 is currently a bad choice for long-term >investments, since the ecosystem is not yet properly developed, and >libraries are still fighting with their API decisions for Python 3.""" > >to: > >"""As it stands, when chos

Re: [Python-Dev] Spreading the Python 3 religion

2012-03-01 Thread Barry Warsaw
On Mar 01, 2012, at 04:42 PM, Antoine Pitrou wrote: >Well, to be honest, "making good progress" currently means "bored and >not progressing at all" :-) But that's not due to the strategy I >adopted, only to the sheer amount of small changes needed, and lack of >immediate motivation to continue thi

Re: [Python-Dev] PEP 414

2012-03-01 Thread Barry Warsaw
On Mar 01, 2012, at 09:42 AM, Guido van Rossum wrote: >I noticed there were some complaints about unnecessarily offensive >language in PEP 414. Have those passages been edited to everyone's >satisfaction? Not yet, but I believe Nick volunteered to do a rewrite. -Barry __

Re: [Python-Dev] PEP 414

2012-03-01 Thread Barry Warsaw
Hopefully, I can say the following in a constructive way. I certainly don't mean to attack anyone personally for their closely held beliefs, though I might disagree with them. And you have the right to those beliefs and to express them in a respectful and constructive manner on this mailing list,

Re: [Python-Dev] PEP 414

2012-03-02 Thread Barry Warsaw
On Mar 02, 2012, at 02:48 PM, Nick Coghlan wrote: >Consider: an application that uses 8-bit strings everywhere and blows up on >non-ASCII data in Python 2 has at least a fighting chance to run unmodified >*and* handle Unicode properly on Python 3. Because unicode literals are gone, >a Unicode-awar

Re: [Python-Dev] PEP 414

2012-03-02 Thread Barry Warsaw
On Mar 02, 2012, at 12:58 PM, Hynek Schlawack wrote: >3.3 is the IMHO the first 3.x release that brings really cool stuff to the >table and might be the tipping point for people to start embracing Python 3 – >despite the fact that Ubuntu LTS will alas ship 3.2 for the next 10 years. I >hope for so

Re: [Python-Dev] PEP 414

2012-03-02 Thread Barry Warsaw
On Mar 02, 2012, at 03:13 PM, Chris McDonough wrote: >FWIW, I think this issue's webness may be overestimated. There happens to be >lots and lots of existing UI code which contains complex interactions between >unicode literals and nonliterals in web apps, but there's also likely lots of >nonweb

Re: [Python-Dev] PEP 414

2012-03-02 Thread Barry Warsaw
On Mar 02, 2012, at 09:23 PM, Hynek Schlawack wrote: >Just to be clear: I didn't say 3.2 is “bad” or “not fine”. It's just the fact >that people need more than “fine” to feel urged to switch to Python 3. I >sincerely hope 3.3 fulfills that and if PEP 414 even makes porting easier we >might have a

Re: [Python-Dev] PEP 414 updated

2012-03-04 Thread Barry Warsaw
On Mar 04, 2012, at 05:34 PM, Nick Coghlan wrote: >My rewritten version of PEP 414 is now up >(http://www.python.org/dev/peps/pep-0414/). It describes in detail a lot more >of the historical background that was taken as read when Guido accepted the >PEP. Nick, really great job with your rewrite o

Re: [Python-Dev] New PEP numbering scheme

2012-03-12 Thread Barry Warsaw
On Mar 12, 2012, at 07:33 PM, Brett Cannon wrote: >It came up at the sprints about how to choose new PEP numbers. It was >agreed that the newest, *lowest* number should be used (e.g. 418) and not >the next highest number (e.g. 3156). I have already updated PEP 1 to >reflect this. +1 -Barry _

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3

2012-03-17 Thread Barry Warsaw
On Mar 17, 2012, at 11:34 PM, barry.warsaw wrote: >http://hg.python.org/cpython/rev/6144a0748a95 >changeset: 75809:6144a0748a95 >branch: 2.6 >parent: 75806:bd9e1a02e3e3 >user: Barry Warsaw >date:Sat Mar 17 18:34:05 2012 -0400 >summary: >

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3

2012-03-17 Thread Barry Warsaw
On Mar 18, 2012, at 12:03 AM, Georg Brandl wrote: >I'm afraid it's the latter: tags are entries in .hgtags. So when you >completely null-merge your 2.6 changes into 2.7, you are basically removing >the tag from the 2.7 branch. And since to find tags, Mercurial looks in the >.hgtags files of all a

Re: [Python-Dev] [Python-checkins] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3

2012-03-17 Thread Barry Warsaw
On Mar 17, 2012, at 07:15 PM, Éric Araujo wrote: >Note that duplicate entries in .hgtags (when a tag was redone) should >not be “cleaned up”: the presence of the old changeset hash greatly >helps conflict resolution. (If someone pulled the repo with the old tag >and later pulls and updates, then

Re: [Python-Dev] regarding HTML mail

2012-03-19 Thread Barry Warsaw
On Mar 19, 2012, at 05:25 PM, Tshepang Lekhonkhobe wrote: >apology: I searched for a few minutes and could not find a code of >conduct regarding HTML mail. I'm not sure it's written down anywhere, but in general we strongly discourage HTML email for the lists @python.org >Can we have some guidel

Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo

2012-04-03 Thread Barry Warsaw
On Apr 03, 2012, at 12:44 AM, Antoine Pitrou wrote: >I don't think Barry still uses bzr, and who ever used git to manage their >patches against the CPython repo? I still use bzr, but not currently for Python development. I just use the standard hg repo. I'd like to go back to it though once the

Re: [Python-Dev] Require loaders set __package__ and __loader__

2012-04-15 Thread Barry Warsaw
On Apr 14, 2012, at 03:32 PM, Guido van Rossum wrote: >Funny, I was just thinking about having a simple standard API that >will let you open files (and list directories) relative to a given >module or package regardless of how the thing is loaded. I tend to use the "basic resource access" API of

Re: [Python-Dev] Require loaders set __package__ and __loader__

2012-04-15 Thread Barry Warsaw
On Apr 15, 2012, at 02:12 PM, Glyph wrote: >Twisted has such a thing, mostly written by me, called >twisted.python.modules. > >Sorry if I'm repeating myself here, I know I've brought it up on this list >before, but it seems germane to this thread. I'd be interested in getting >feedback from the i

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

2012-04-16 Thread Barry Warsaw
On Apr 15, 2012, at 01:13 PM, Raymond Hettinger wrote: >We should publish some advice on creating content managers. I agree, I'm just not sure PEP 8 is the right place for it. PEP 8 seems like it is structured more as mechanical guidelines for the look and feel of code, not so much for the seman

Re: [Python-Dev] importlib is now bootstrapped (and what that means)

2012-04-16 Thread Barry Warsaw
On Apr 16, 2012, at 07:44 PM, Antoine Pitrou wrote: >Wouldn't it be better if Python could compile regardless of the >presence of a hg repository? If you want it in your $DISTRO, yes please! -Barry ___ Python-Dev mailing list Python-Dev@python.org http

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

2012-04-17 Thread Barry Warsaw
On Apr 17, 2012, at 08:25 AM, R. David Murray wrote: >On Tue, 17 Apr 2012 08:53:43 +0200, Matej Cepl wrote: >> On 16.4.2012 18:10, Nam Nguyen wrote: >> > a_list[pos + 1 : -1] >> >> or other way around >> >> a_list[pos+1:-1] > > >That's what I always use. No spaces inside the brackets for me :)

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

2012-04-19 Thread Barry Warsaw
On Apr 18, 2012, at 09:26 PM, Guido van Rossum wrote: >On Wed, Apr 18, 2012 at 8:14 PM, Chris Angelico wrote: >> On Thu, Apr 19, 2012 at 1:06 PM, Eli Bendersky wrote: >>> (quoting GvR) Let's change this to something more reasonable, e.g. """ If operators with different priori

Re: [Python-Dev] Suggested addition to PEP 8 for context managers

2012-04-19 Thread Barry Warsaw
On Apr 19, 2012, at 11:00 AM, Éric Araujo wrote: >Hi, > >> +- If operators with different priorities are used, consider adding >> + whitespace around the operators with the lowest priority(ies). This >> + is very much to taste; however, never use more than one space, and >> + always have the sa

Re: [Python-Dev] Handling deprecations in the face of PEP 384

2012-04-21 Thread Barry Warsaw
On Apr 20, 2012, at 09:59 PM, Brett Cannon wrote: >As I clean up Python/import.c and move much of its functionality into >Lib/imp.py, I am about to run into some stuff that was not kept private to >the file. Specifically, I have PyImport_GetMagicTag() and NullImporter_Type >which I would like to c

Re: [Python-Dev] netiquette on py-dev

2012-04-25 Thread Barry Warsaw
On Apr 25, 2012, at 12:44 PM, Stephen J. Turnbull wrote: >Note that people who are really annoyed by the duplicates can set >their Mailman accounts to no-dupes, and Mailman won't send the post to >that person. (This has its disadvantages in principle -- no List-* >headers and other list-specific

Re: [Python-Dev] netiquette on py-dev

2012-04-25 Thread Barry Warsaw
On Apr 25, 2012, at 01:58 PM, Chris Angelico wrote: >I go the other way: hit Reply, and then replace the author's address >with the list's. I'd much rather have a Reply List though. >Unfortunately no decent webmail seems to have it, and I'm still >looking for a decent non-web-mail client too. It'

[Python-Dev] Python 3 porting

2012-04-25 Thread Barry Warsaw
I want to take this opportunity to make folks aware of several Python 3 porting initiatives and resources. In Ubuntu 12.10, we are going to be making a big push to target all the applications and libraries on the desktop CDs to Python 3. While this is a goal of Ubuntu, the intent really is to wor

Re: [Python-Dev] sys.implementation

2012-04-26 Thread Barry Warsaw
On Apr 25, 2012, at 11:31 PM, Eric Snow wrote: >The proposal of adding sys.implementation has come up a couple times >over the last few years. [1][2] While the reaction has been >overwhelmingly positive, nothing has come of it. I've created a >tracker issue and a patch: > >http://bugs.python

Re: [Python-Dev] The step command of pdb is broken

2012-04-30 Thread Barry Warsaw
On Apr 30, 2012, at 08:42 AM, Guido van Rossum wrote: >IT would be good if the author of one of the pdb add-ons such as (I >believe) pdb2 could comment on this bug. Maybe we should take this opportunity (Python 3.3) to consider adopting one of the pdb add-ons or borging the best of their bits int

Re: [Python-Dev] Email6 status (was Open PEPs and large-scale changes for 3.3)

2012-05-01 Thread Barry Warsaw
On May 01, 2012, at 10:40 AM, R. David Murray wrote: >I guess it's time to talk about my plans for this one :) Thanks for the update RDM. I really wish I had more time to contribute to email6, but I'd still really like to see this land in 3.3 if possible. I suspect you're just not going to get

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

2012-05-01 Thread Barry Warsaw
On May 01, 2012, at 11:30 PM, Nick Coghlan wrote: >> * Breaking out standard library and docs in separate repos? > >Our current development infrastructure simply isn't set up to cope >with this. With both 407 and 413 still open (and not likely to go >anywhere any time soon), this simply isn't goin

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

2012-05-01 Thread Barry Warsaw
On May 01, 2012, at 08:24 AM, Eric V. Smith wrote: >Oops, I missed your reference to PEP 402 and PEP 420. Sorry about that. > >It is indeed 420 that would replace 402. And the older PEP 382. Once 420 is accepted, we should simply reject 382 and 402. At that point, I'll update them to point to 4

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages

2012-05-05 Thread Barry Warsaw
On May 05, 2012, at 04:04 PM, Christian Heimes wrote: >The fix needs the dpkg-architecture program. As Tshepang pointed out it >may not be available on Edward's box. I always install build-essential >on all development boxes as it includes GCC, make and dpkg-dev. That's probably it. Certainly Py

Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice

2012-05-05 Thread Barry Warsaw
Thanks for doing this update Nick. I have just a few comments. On May 05, 2012, at 02:57 PM, nick.coghlan wrote: >+Developers with commit privileges for the `PEP repository`_ may claim >+PEP numbers directly by creating and committing a new PEP. When doing so, >+the developer must handle the tas

Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice

2012-05-05 Thread Barry Warsaw
On May 05, 2012, at 12:56 PM, Barry Warsaw wrote: >before the final PEP can be approved. When an `PEP-Czar` header must be >added to the PEP to record this delegation. The format of this header is >the same as the `Author` header. s/When an/A

Re: [Python-Dev] Recording BDFL delegates for PEPs

2012-05-06 Thread Barry Warsaw
On May 06, 2012, at 09:31 AM, Antoine Pitrou wrote: >I have to ask - is email obfuscation still useful these days? I think it's more important that Python developers (especially those submitting or pronouncing on PEPs) can be contacted by other Python developers. I *personally* don't care about

Re: [Python-Dev] [Python-checkins] peps: Update PEP 1 to better reflect current practice

2012-05-06 Thread Barry Warsaw
On May 06, 2012, at 03:08 PM, Nick Coghlan wrote: >I'll see if I can figure out something - I may just put in text like >"if you're at all unsure about what needs to be done, email the PEP >editors anyway". The diff looks good, thanks. -Barry ___ Pytho

Re: [Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can

2012-05-07 Thread Barry Warsaw
On May 07, 2012, at 04:42 PM, Edward C. Jones wrote: >I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled >and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes >with python3.2 (and 2.6 and 2.7). I installed the Debian package >python3-bs4 (BeautifulSou

Re: [Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can

2012-05-08 Thread Barry Warsaw
On May 08, 2012, at 11:13 AM, Brett Cannon wrote: >This really isn't the right mailing list to ask this kind of question (I >know you got help last time with your Debian-specific problem, but that was >because people got overly excited =). Python-dev is meant for discussing >the development *of* P

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-08 Thread Barry Warsaw
On May 08, 2012, at 11:59 AM, Nick Coghlan wrote: >No, the "mcl" in the call is just the designated metaclass - the >*actual* metaclass of the resulting class definition may be something >different. That's why this is a separate method from mcl.__new__. I'm not completely sold on adding a class m

Re: [Python-Dev] sys.implementation

2012-05-08 Thread Barry Warsaw
Hi Eric, Great job on the latest PEP 421. I really like it. A few additional comments/questions. * sys.implementation.version This is defined as the version of the implementation, while sys.version_info is the version of the language. The semantics of sys.version_info have been suff

Re: [Python-Dev] Debian wheezy, amd64: make not finding files for bz2 and other packages

2012-05-08 Thread Barry Warsaw
On May 09, 2012, at 02:17 AM, Matthias Klose wrote: >IMO, the correct fix would be not to hard-code the system include and library >directories, but get them from gcc directly (if CC is gcc), and not relying on >dpkg-architecture. > >$ gcc -v -E - [...] >#include <...> search starts here: > /usr/l

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-09 Thread Barry Warsaw
On May 09, 2012, at 05:20 PM, Nick Coghlan wrote: >Ah, good point. In that case, consider me convinced: static method it >is. It can join mro() as the second non-underscore method defined on >type(). +1 If I may dip into the bikeshed paint once more. I think it would be useful to establish a na

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw
On May 08, 2012, at 09:03 PM, Eric Snow wrote: >>   This is defined as the version of the implementation, while >>   sys.version_info is the version of the language.  The semantics of >>   sys.version_info have been sufficiently squishy in the past, as the XXX >>   implies.  This PEP shouldn't try

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw
On May 09, 2012, at 08:51 AM, Eric Snow wrote: >The type for sys.implementation has slowly shifted from the original >proposal. At this point it's settled into where I think it will stay, >a custom type. I've covered the choice of type in the rationale >section. However, there may be merit in n

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw
On May 09, 2012, at 11:09 AM, Brett Cannon wrote: >Sure, but couldn't we define this "empty" class in C code so that you can >use the C API with it as well and just provide a C function to get a new >instance? +1 ISTM to be a companion to collections.namedtuple. IWBNI this new type was also exp

Re: [Python-Dev] sys.implementation

2012-05-09 Thread Barry Warsaw
On May 09, 2012, at 05:47 PM, Larry Hastings wrote: >I like Alex Martelli's approach, which I recall was exactly this: > >class namespace: > def __init__(**kwargs): > self.__dict__ = kwargs > > >That means all the initializers you pass in to the constructor get turned >into

Re: [Python-Dev] Adding types.build_class for 3.3

2012-05-10 Thread Barry Warsaw
On May 09, 2012, at 07:44 PM, R. David Murray wrote: >On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan wrote: >> Given that the statement form is referred to as a "class definition", and >> this is the dynamic equivalent, I'm inclined to go with "type.define()". >> Dynamic type definition is more

Re: [Python-Dev] sys.implementation

2012-05-10 Thread Barry Warsaw
On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote: >sys.implementation.metadata looks like a completely over-engineered >concept. Please, let's just make sys.implementation a dict and stop >bothering about ordering and iterability. I guess the question is whether immutability is useful to preser

Re: [Python-Dev] sys.implementation

2012-05-12 Thread Barry Warsaw
On May 12, 2012, at 10:04 PM, Nick Coghlan wrote: >On Sat, May 12, 2012 at 12:40 PM, Eric Snow >wrote: > If anyone has strong feelings for item-access over attribute-access, >> please elaborate.  I'm just not seeing it as that important and would > >rather finish up the PEP as simply as possible.

Re: [Python-Dev] Accepting PEP 415 (alternative implementation strategy for PEP 409's "raise exc from None" syntax)

2012-05-14 Thread Barry Warsaw
On May 14, 2012, at 10:04 PM, Nick Coghlan wrote: >As the subject line says, as Guido's delegate, I'm accepting >Benjamin's PEP 415 with the current reference implementation. I'm glad to see this PEP get accepted. I have just minor quibbles :). Can you or Benjamin improve the title of the PEP?

Re: [Python-Dev] sys.implementation

2012-05-15 Thread Barry Warsaw
On May 15, 2012, at 10:26 AM, Eric Snow wrote: >At this point I'm pretty comfortable with where PEP 421 is at. Before >asking for pronouncement, I'd like to know if anyone has any >outstanding concerns that should be addressed first. It looks great to me. If I were the PEP czar , I'd approve it

[Python-Dev] docs.python.org pointing to Python 3 by default?

2012-05-18 Thread Barry Warsaw
At what point should we cut over docs.python.org to point to the Python 3 documentation by default? Wouldn't this be an easy bit to flip in order to promote Python 3 more better? Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

2012-05-18 Thread Barry Warsaw
On May 18, 2012, at 11:36 AM, Benjamin Peterson wrote: >2012/5/18 Barry Warsaw : >> At what point should we cut over docs.python.org to point to the Python 3 >> documentation by default?  Wouldn't this be an easy bit to flip in order to >> promote Python 3 more better?

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

2012-05-21 Thread Barry Warsaw
On May 20, 2012, at 04:27 PM, Raymond Hettinger wrote: >When there is more uptake of Python 3, it would be reasonable move. How do we measure this, and what's the milestone for enough uptake to make the switch? Cheers, -Barry signature.asc Description: PGP signature ___

Re: [Python-Dev] docs.python.org pointing to Python 3 by default?

2012-05-21 Thread Barry Warsaw
On May 21, 2012, at 02:28 PM, Nick Coghlan wrote: >Rather than a new subdomain, I'd prefer to see a discreet >"documentation version" CSS widget, similar to that used in the Django >docs (see https://docs.djangoproject.com/en/1.4/) that indicated the >current displayed version and provided quick l

[Python-Dev] Volunteering to be PEP czar for PEP 421, sys.implementation

2012-05-21 Thread Barry Warsaw
I've mentioned this in private to a few folks, with generally positive feedback. I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If there are no objections in the next few days, I'll make it official. Cheers, -Barry signature.asc Description: PGP signature __

Re: [Python-Dev] PEP 420 - dynamic path computation is missing rationale

2012-05-22 Thread Barry Warsaw
Minor nit. On May 22, 2012, at 04:43 PM, PJ Eby wrote: >def declare_namespace(package_name): > parent, dot, tail = package_name.rpartition('.') > attr = '__path__' > if dot: >declare_namespace(parent) > else: >parent, attr = 'sys', 'path' > with importlockconte

Re: [Python-Dev] An infinite loop in dictobject.c

2012-05-24 Thread Barry Warsaw
On May 25, 2012, at 06:07 AM, Nick Coghlan wrote: >If it only started happening recently, suspicion would naturally fall on >the hash randomisation security fix (as I assume a new version of Python >would have been pushed for 10.04 with that update) I do not think the hash randomization patch has

Re: [Python-Dev] [Python-checkins] cpython: issue 14660: Implement PEP 420, namespace packages.

2012-05-25 Thread Barry Warsaw
On May 25, 2012, at 10:31 AM, Brett Cannon wrote: >Is documentation coming in a separate commit? Yes. I've been reworking the import machinery documentation; it's a work-in-progress on the pep-420 feature clone ('importdocs' branch). I made some good progress and then got side-tracked, but I'm

Re: [Python-Dev] Volunteering to be PEP czar for PEP 421, sys.implementation

2012-05-25 Thread Barry Warsaw
On May 21, 2012, at 05:24 PM, Barry Warsaw wrote: >I've mentioned this in private to a few folks, with generally positive >feedback. > >I am formally volunteering to be PEP czar for PEP 421, sys.implementation. If >there are no objections in the next few days, I'll make

Re: [Python-Dev] sys.implementation

2012-05-25 Thread Barry Warsaw
On May 17, 2012, at 07:19 AM, Eric Snow wrote: >PEP 421 has reached a good place and I'd like to ask for pronouncement. As the newly self-appointed PEP 421 czar, I hereby accept this PEP. Eric, you've done a masterful job at balancing and addressing the input from the Python development communit

Re: [Python-Dev] a new type for sys.implementation

2012-05-31 Thread Barry Warsaw
On May 31, 2012, at 01:21 AM, Eric Snow wrote: >The implementation for sys.implementation is going to use a new (but >"private") type[1]. It's basically equivalent to the following: > >class namespace: >def __init__(self, **kwargs): >self.__dict__.update(kwargs) >def __repr__(self

Re: [Python-Dev] a new type for sys.implementation

2012-05-31 Thread Barry Warsaw
On May 31, 2012, at 10:31 PM, Nick Coghlan wrote: >Personally, I suggest we just expose the new type as >types.SimpleNamespace (implemented in Lib/types.py as "SimpleNamespace >= type(sys.implementation)" and call it done. Great idea, +1. Eric, if you want to remove the special case for _names i

Re: [Python-Dev] a new type for sys.implementation

2012-06-01 Thread Barry Warsaw
On Jun 01, 2012, at 11:49 PM, Nick Coghlan wrote: >The long term goal here is that all the code in the standard library >should be implementation independent - PyPy, Jython, IronPython, et al >should be able to grab it and just run it. That means the >implementation specific stuff needs to migrate

Re: [Python-Dev] a new type for sys.implementation

2012-06-01 Thread Barry Warsaw
On Jun 01, 2012, at 03:22 PM, Mark Shannon wrote: >I thought this list was for CPython, not other implementations ;) This list serves a dual purpose. Its primary purpose is to discuss development of Python-the-language. It's also where discussions about CPython-the-implementation occur, but tha

Re: [Python-Dev] whither PEP 407 and 413 (release cycle PEPs)?

2012-06-03 Thread Barry Warsaw
On Jun 03, 2012, at 01:22 PM, Martin v. Löwis wrote: >- Some people (Barry in particular) are in favor of timed releases. > I don't know what the actual motivation for timed releases is, but Timed releases in general can provide much better predictability for others depending on those releases.

Re: [Python-Dev] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

2012-06-04 Thread Barry Warsaw
Thanks for the second set of eyes, Brett. On Jun 04, 2012, at 10:16 AM, Brett Cannon wrote: >> +.. data:: implementation >> + >> + An object containing the information about the implementation of the >> + currently running Python interpreter. Its attributes are the those >> > >"the those" ->

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

2012-06-04 Thread Barry Warsaw
On Jun 04, 2012, at 01:19 PM, Dirkjan Ochtman wrote: >I recently opened issue14908. At work, I have to do a bunch of things >with dates, times and timezones, and sometimes Unix timestamps are >also involved (largely for easy compatibility with legacy APIs). I >find the relative obscurity when conv

Re: [Python-Dev] Issue 2736: datetimes and Unix timestamps

2012-06-04 Thread Barry Warsaw
On Jun 04, 2012, at 02:18 PM, Dirkjan Ochtman wrote: >Personally, I would really like not having to think about the time >module at all, except if I wanted to go low-level (e.g. get a Unix >timestamp from scratch). +1 Oh and, practicality beats purity. -Barry ___

Re: [Python-Dev] [Python-checkins] cpython: Eric Snow's implementation of PEP 421.

2012-06-04 Thread Barry Warsaw
On Jun 04, 2012, at 11:39 AM, Brett Cannon wrote: >OK, then I would add a test to make sure this happens, like >``self.assertEqual(sys.implementation.name, sys.implement.name.lower())`` >if you don't want to bother documenting it to make sure other VMs conform. Good idea. Done. -Barry signatu

Re: [Python-Dev] TZ-aware local time

2012-06-05 Thread Barry Warsaw
On Jun 05, 2012, at 07:41 PM, Alexander Belopolsky wrote: >The second feature has its uses. If I want wake up at 7 AM every >weekday, I don't want my alarm clock ask me whether I mean standard or >daylight saving time, but if I attempt to set it to 1:30 AM on the day >when 1:30 AM happens twice,

Re: [Python-Dev] Open PEPs and large-scale changes for 3.3

2012-06-06 Thread Barry Warsaw
On Jun 06, 2012, at 05:55 PM, Ben Finney wrote: >The PEP document currently says it targets “3.x”. I'll leave it in that >state until we're more confident that the current work will be on track >for a particular Python release. > >Do I need to do anything in particular to be explicit that PEP 3143

Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython

2012-06-11 Thread Barry Warsaw
On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote: >1. Asking on python-dev is considered adequate. If an implementation >wants to be consulted on changes, one or more of their developers >*must* follow python-dev sufficiently closely that they don't miss >cross-VM compatibility questions. That's

Re: [Python-Dev] Status of packaging in 3.3

2012-06-21 Thread Barry Warsaw
On Jun 21, 2012, at 07:48 AM, Chris McDonough wrote: >I don't know about Red Hat but both Ubuntu and Apple put all kinds of stuff >on the default sys.path of the system Python of the box that's related to >their software's concerns only. I don't understand why people accept this >but get crazy ab

Re: [Python-Dev] Status of packaging in 3.3

2012-06-21 Thread Barry Warsaw
On Jun 21, 2012, at 08:51 AM, Chris McDonough wrote: >The reason it's disappointing to see OS vendors mutating the default sys.path >is because they put *very old versions of very common non-stdlib packages* >(e.g. zope.interface, lxml) on sys.path by default. The path is tainted out >of the box

Re: [Python-Dev] Status of packaging in 3.3

2012-06-22 Thread Barry Warsaw
On Jun 22, 2012, at 12:27 PM, Paul Moore wrote: >And what I am trying to say is that no matter how much effort gets put >into trying to make build from source easy, it'll pretty much always >not be even remotely trivial on Windows. It seems to me that a "Windows build service" is something the Py

<    18   19   20   21   22   23   24   25   26   27   >