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

On Jun 22, 2012, at 07:49 AM, Vinay Sajip wrote: >The format-neutral alternative I used for logging configuration was a >dictionary schema - JSON, YAML and Python code can all be mapped to >that. Perhaps the relevant APIs can work at the dict layer. I don't much care whether it's ini, json, or ya

Re: [Python-Dev] Restricted API versioning

On Jun 24, 2012, at 12:08 AM, Martin v. Löwis wrote: >Please propose something. I think the hexversion *is* user-friendly, >since it allows easy comparisons (Py_LIMITED_API+0 >= 0x0303). >Users that run into missing symbols will, after inspection of the >header file, easily know what to do. +

Re: [Python-Dev] cpython: Issue #15177: Added dir_fd parameter to os.fwalk().

On Jun 25, 2012, at 02:17 PM, Antoine Pitrou wrote: >On Mon, 25 Jun 2012 13:49:14 +0200 >larry.hastings wrote: >> http://hg.python.org/cpython/rev/7bebd9870c75 >> changeset: 0:7bebd9870c75 >> user:Larry Hastings >> date:Mon Jun 25 04:49:05 2012 -0700 >> summary: >> Issue

Re: [Python-Dev] [Python-ideas] itertools.chunks(iterable, size, fill=None)

On Jul 05, 2012, at 04:36 PM, anatoly techtonik wrote: >It would be much easier to do this in unified interface for threaded >discussions, but for now there is no capabilities for that neither in Mailman >nor in GMail. You might like to read the mailing lists via NNTP on Gmane. Cheers, -Barry __

[Python-Dev] Issue 15295: New import documentation

Back when Eric, Jason, and I sprinted on the PEP 420 implementation, I threatened to actually document how the import machinery worked, updating and reorganizing to include the new PEP 420 protocols. Issue 15295 tracks this: http://bugs.python.org/issue15295 I now have a first draft of the new i

[Python-Dev] python-checkins moderation

I just freed up a bunch, but not all, of the messages to python-checkins being held for moderator approval. We could use some additional moderator volunteers. I'm not sure Fred is still moderating the list, and I suck at it. Please email me directly if you'd like to help out, have experience mod

Re: [Python-Dev] python 3.3 b2

On Jul 30, 2012, at 10:22 PM, Georg Brandl wrote: >As I've explained on python-committers, it's currently on hold pending >the resolution of some importlib issues as well as a bug with the >cross-compiling code. I won't issue a concrete date, but I expect the >release to be made some time before

Re: [Python-Dev] [Python-checkins] cpython: Issue #15502: Bring the importlib.PathFinder docs and docstring more in line

On Aug 02, 2012, at 03:04 PM, nick.coghlan wrote: >http://hg.python.org/cpython/rev/1f8351cf00f3 >changeset: 78382:1f8351cf00f3 >user:Nick Coghlan >date:Thu Aug 02 23:03:58 2012 +1000 >summary: > Issue #15502: Bring the importlib.PathFinder docs and docstring more in line > wi

Re: [Python-Dev] [Python-checkins] cpython: s/path importer/path based finder/ (because the path based finder is not an

On Aug 20, 2012, at 05:49 AM, nick.coghlan wrote: > s/path importer/path based finder/ (because the path based finder is not an > importer and the simpler 'path finder' is too ambiguous) +1! -Barry ___ Python-Dev mailing list Python-Dev@python.org ht

[Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

Issue 15906 describes a problem with argparse that is breaking lots of code in Ubuntu. This is a recent regression caused by the fix for issue 12776, and it affects Python 2.7, 3.2, and 3.3. I posted a diff that should fix the problem, but at the heart of it is a semantic ambiguity in argparse th

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 12:19 PM, R. David Murray wrote: >The 12776 fix isn't going to be in 3.3, so I don't think this is a >pressing issue. We can take our time to make sure we have the correct >fix. It is, however, a release blocker for 2.7.4, 3.2.4, and 3.3.1. Are you sure about that? % ./pyth

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 03:08 PM, Barry Warsaw wrote: >Are you sure about that? > >% ./python >Python 3.3.0rc2+ (default:6fea947edead, Sep 11 2012, 15:03:16) Never mind. Georg didn't pull that patch into his release clone. (Aside: Georg, maybe you could fiddle with the default

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 01:17 PM, Terry Reedy wrote: >This second example strikes me (naively, as English speaker but not argparse >user) as 'wrong' in that 'default' is being misused to mean 'start value that >is always used to generate the final value' [as in sum(iterable, start=0)], >rather than 'f

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 10:39 AM, Chris Jerdonek wrote: >So another way out could simply be not to call type on non-strings. >Indeed, this was done before. One of the changes that was made in the >patch for issue 12776 was to remove the str type check prior to >calling type. Yep, so probably that's

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 12:19 PM, R. David Murray wrote: >There is another possible semantic, which is that when the store type is >append, the converter should be applied to each of the individual items in >the default list. Yep. Maybe for 3.4 . >Which brings us to another issue: as things stand n

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 10:13 PM, Georg Brandl wrote: >> Traceback (most recent call last): >> File "/home/barry/projects/python/3.3.0/Parser/asdl.py", line 309, in visit >> meth(object, *args) >> File "./Parser/asdl_c.py", line 1043, in visitSum >> self.simpleSum(sum, name) >> File "./P

Re: [Python-Dev] Issue 15906; regression in argparse in Python 3.3, 3.2, and 2.7

On Sep 11, 2012, at 05:30 PM, Terry Reedy wrote: >> And yet, that's how it works in 2.7, 3.2, and 3.3.1. > >In all 2.7 or 3.2? It will be broken in 2.7.4 and 3.2.4, but the Ubuntu packages in 12.10 are currently affected because they pulled in some Mercurial updates which included these unrelease

Re: [Python-Dev] [Python-checkins] cpython (merge 3.2 -> default): - Issue #15906: Fix a regression in argparse caused by the preceding change,

On Sep 11, 2012, at 09:30 PM, Chris Jerdonek wrote: >I didn't have time to respond Barry's e-mail from four hours ago >before this was committed. I think this change may be problematic. >At the least, I think people should have an opportunity to air their >specific concerns and talk through the i

Re: [Python-Dev] [Python-checkins] peps: 3.2 and 3.3 release schedules: add information on bugfix releases and release

On Oct 01, 2012, at 06:57 PM, Nick Coghlan wrote: >On Mon, Oct 1, 2012 at 5:51 PM, georg.brandl >wrote: >> +3.3.1 schedule >> +-- >> + >> +- 3.3.1 beta 1: planned for Oct/Nov 2012 > >Copy and paste error from the 3.2 PEP? > >And thanks for adding these - very handy. Agreed. Perhaps

Re: [Python-Dev] Stdlib and timezones, again

On Oct 01, 2012, at 03:34 PM, Lennart Regebro wrote: >On Mon, Oct 1, 2012 at 3:22 PM, Nick Coghlan wrote: > >> 1. Consider TZ database updates to be bug fixes, and thus include them >> in maintenance releases. This will keep the provided version >> reasonably fresh for Python versions that are st

Re: [Python-Dev] Stdlib and timezones, again

On Sep 30, 2012, at 02:47 PM, Lennart Regebro wrote: >The problem with including pytz in the stdlib is that it contains the >tz/zoneinfo/Olson database, and it updates much more often than Python >does. Why include the database in Python at all? If you have an OS that keeps the system tz data up

Re: [Python-Dev] Stdlib and timezones, again

On Oct 01, 2012, at 05:15 PM, Lennart Regebro wrote: >On Mon, Oct 1, 2012 at 5:11 PM, Barry Warsaw wrote: > >> I completely agree that just installing the Cheeseshop tz package should >> *not* be enough to prefer it over the system tz data. > >Do you have another pot

Re: [Python-Dev] Stdlib and timezones, again

On Oct 01, 2012, at 05:29 PM, Lennart Regebro wrote: >We seem to be on the same page here. Well, that was easy! Maybe I should be your PEP Czar :) -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http

Re: [Python-Dev] Stdlib and timezones, again

On Oct 02, 2012, at 12:18 AM, Nick Coghlan wrote: >Reminder to everyone: the current state of the art for getting up to >date tz info for Python is "pip install pytz". > >If any proposal is more complicated than that, there's absolutely no >point in changing anything. The version I liked best so f

Re: [Python-Dev] Proposed schedule for Python 3.4

On Oct 03, 2012, at 06:45 AM, Skip Montanaro wrote: >Is there a rough list of changes for 3.4 written down somewhere Let the wild rumpus begin! -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Proposed schedule for Python 3.4

On Oct 03, 2012, at 11:22 AM, R. David Murray wrote: >I don't have any data to back this up, but it is my impression that more >distributions are providing access to alpha releases in their "testing" >package trees. Ubuntu and Debian generally does, thanks to Matthias's great work. Python 3.3's

Re: [Python-Dev] Issue #16153: PyUnicode_FromFormatV() must fail if the format string is invalid

On Oct 07, 2012, at 11:09 PM, Victor Stinner wrote: >Does anyone know if there is a good reason why PyUnicode_FromFormatV() >does not fail on invalid format string, but copies the format string >as-if into the result? > >I would like to change this to raise a ValueError instead. >PyUnicode_FromFor

Re: [Python-Dev] Issue #16153: PyUnicode_FromFormatV() must fail if the format string is invalid

On Oct 08, 2012, at 11:23 PM, Victor Stinner wrote: >2012/10/8 Barry Warsaw : >>>Does anyone know if there is a good reason why PyUnicode_FromFormatV() >>>does not fail on invalid format string, but copies the format string >>>as-if into the result? >>> &g

Re: [Python-Dev] AUTO: Jon K Peck is out of the office

On Oct 15, 2012, at 11:40 AM, Brian Curtin wrote: >On Mon, Oct 15, 2012 at 11:04 AM, Jon K Peck wrote: >> I am out of the office until 10/16/2012. >> >> I will be out of the office Monday 10/15/12. I will not have email access >> during this time. >> >> >> Note: This is an automated response to

Re: [Python-Dev] Bumping autoconf from 2.68 to 2.69

On Oct 16, 2012, at 05:32 AM, Trent Nelson wrote: > Anyway, back to the original question: does anyone know of reasons > we shouldn't bump to 2.69? Any known incompatibilities? There will be problems building with 2.69 on Ubuntus older than 12.10, and Debians older than wheezy. % rmadison autoc

Re: [Python-Dev] Rejecting PEPs 407 and 413?

On Oct 19, 2012, at 09:33 PM, Nick Coghlan wrote: >At the moment, with the "3.4" used throughout the examples in both >PEPs, it's a little confusing w.r.t the actual 3.4 release PEP. I >could live with "Deferred" instead of "Rejected", but one or the other >should happen. I no longer have much in

Re: [Python-Dev] PEP 426 comment: field order

On Oct 18, 2012, at 09:23 PM, Daniel Holth wrote: >The email module provides an ordered multidict interface to the data. >The first tag wins (if you improperly define Name: twice for example), >but the order of everything is preserved. We just don't need it, >except that it might be surprising to

Re: [Python-Dev] accept the wheel PEPs 425, 426, 427

On Oct 19, 2012, at 08:07 PM, Daniel Holth wrote: >The email parser is significantly more permissive than the RFC. Don't forget that the email package now supports policies (experimentally), so it may be possible to tweak a policy setting to fit the bill. Anyway, it might at least be interesting

Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows

On Oct 22, 2012, at 03:40 PM, Victor Stinner wrote: >The issue #8766 is about PYTHONPATH environment variable, not >PYTHONHOME. Test on Linux with Python 3.4: > >$ PYTHONHOME=/x ./python >Fatal Python error: Py_Initialize: Unable to get the locale encoding >ImportError: No module named 'encodings'

Re: [Python-Dev] Segmentaion fault with wrongly set PYTHONPATH on Windows

On Oct 22, 2012, at 04:30 PM, Christian Heimes wrote: >I think it's a bug in lsb_release, too. It should use the -E option in >its shebang: Indeed, thanks! I'd forgotten about -E. (bug updated btw) -Barry signature.asc Description: PGP signature __

Re: [Python-Dev] Split unicodeobject.c into subfiles

On Oct 25, 2012, at 08:15 AM, Nick Coghlan wrote: >OK, I need to weigh in after seeing this kind of reply. Large source files >are discouraged in general because they're a code smell that points >strongly towards a *lack of modularity* within a *complex piece of >functionality*. Modularity is goo

Re: [Python-Dev] [Python-checkins] peps: PEP 430 is Final.

On Oct 28, 2012, at 09:21 AM, georg.brandl wrote: > PEP 430 is Final. >From the PEP: "The existing /py3k/ subpath would be remapped to the new /3/ subpath." Does "remapped" mean redirects so as not to break the existing py3k urls? If so, then cool. Cheers, -Barry

Re: [Python-Dev] Acceptance of PEPs

On Oct 28, 2012, at 11:05 PM, Brian Curtin wrote: >I just found out that PEP 430 came up again and was approved, but only >because of another website. After that I looked back through my email >only to find mention via python-checkins. Aren't PEPs typically acted >on here on python-dev? > >I menti

Re: [Python-Dev] [Distutils] accept the wheel PEPs 425, 426, 427

I'm just beginning to review these PEPs and the threads, with an OS vendor packager's eye. Let me start with one small suggestion for PEP 425. From the FAQ: Q. Who will maintain the registry of abbreviated implementations? A. New two-letter abbreviations can be requested on the python-dev maili

Re: [Python-Dev] [Python-checkins] cpython (3.3): - Issue #16514: Fix regression causing a traceback when sys.path[0] is None

On Nov 20, 2012, at 05:12 PM, Brett Cannon wrote: >Should you also insert None into sys.path_importer_cache to signify there >is no finder for the path entry? I guess the real problem with that is >there is no guarantee the path entry is hashable, so that probably won't >work. So nevermind. =) I

Re: [Python-Dev] [Python-checkins] cpython (3.3): - Issue #16514: Fix regression causing a traceback when sys.path[0] is None

On Nov 20, 2012, at 05:35 PM, Terry Reedy wrote: >On 11/20/2012 3:35 PM, barry.warsaw wrote: > >> for entry in path: >> +if not isinstance(entry, (str, bytes)): >> +continue > >Given that a non-(str,bytes) entry could indicate a programming error, should >a wa

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

On Dec 03, 2012, at 02:29 PM, Larry Hastings wrote: >4) Builtin function arguments are defined in a small DSL; these >are expanded to code and data using a custom compile-time >preprocessor step. > >All the core devs I've asked said "given all that, I'd prefer the >hairy preprocessor macro

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

On Dec 04, 2012, at 11:47 AM, David Malcolm wrote: >As noted elsewhere, sane generated C code is much easier to step through >in the debugger than preprocessor macros (though "sane" in that sentence >is begging the question, I guess, but the examples you post look good to >me). And to me too. -B

Re: [Python-Dev] Proposing "Argument Clinic", a new way of specifying arguments to builtins for CPython

On Dec 04, 2012, at 10:48 PM, Antoine Pitrou wrote: >I think the DSL itself does warrant public exposure. It will be an >element of the CPython coding style, if its use becomes widespread. We do have PEP 7 after all. No matter what, this stuff has to eventually be well documented outside of the

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Dec 05, 2012, at 04:10 PM, PJ Eby wrote: >While it's certainly desirable to not invent wheels, it's important to >understand that the Python community does not work the same way as a >Linux distribution. We are not a single organization shipping a >fully-functional and configured machine, we a

Re: [Python-Dev] Keyword meanings [was: Accept just PEP-0426]

On Dec 05, 2012, at 06:07 PM, Donald Stufft wrote: >If you're installing B you've prescribed trust to that author. If you don't >trust the author then why are you installing (and then executing) code >they wrote. What you installed Z, but B got installed because it was a dependency three levels

[Python-Dev] Emacs users: hg-tools-grep

Hark fellow Emacsers. All you unenlightened heathens can stop reading now. A few years ago, my colleague Jono Lange wrote probably the best little chunk of Emacs lisp ever. `M-x bzr-tools-grep` lets you easily search a Bazaar repository for a case-sensitive string, providing you with a nice *gre

Re: [Python-Dev] More compact dictionaries with faster iteration

On Dec 10, 2012, at 08:48 AM, Christian Heimes wrote: >It's hard to predict how the extra CPU instructions are going to affect >the performance on different CPUs and scenarios. My guts tell me that >your proposal is going to perform better on modern CPUs with lots of L1 >and L2 cache and in an ave

Re: [Python-Dev] More compact dictionaries with faster iteration

On Dec 10, 2012, at 05:39 PM, Christian Heimes wrote: >I had ARM platforms in mind, too. Unfortunately we don't have any ARM >platforms for testing and performance measurement. Even Trent's >Snakebite doesn't have ARM boxes. I've a first generation Raspberry Pi, >that's all. I have a few ARM mach

Re: [Python-Dev] Emacs users: hg-tools-grep

On Dec 10, 2012, at 03:02 PM, Brandon W Maister wrote: >I also feel weird about adding a copyright to this, but how will other >people feel comfortable using it if I don't? Nice! I've been told that Emacs 23 is probably a minimum requirement because locate-dominating-file is missing in <= Emacs

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote: >This PEP is also available on github: > >https://github.com/regebro/tz-pep/blob/master/pep-04tz.txt wget returns some html gobbledygook. Why-oh-why github?! >PEP: 4?? I've assigned this PEP 431, reformatted a few extra wide paragraphs, comm

Re: [Python-Dev] Draft PEP for time zone support.

Great work, Lennart. I really like this PEP. Feedback follows (I haven't yet read the rest of the messages in this thread ;). On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote: >This PEP proposes to add these ``is_dst`` parameters to the relevant methods >of the ``datetime`` API, and therefor

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 11, 2012, at 03:48 PM, Paul Moore wrote: >I agree. Also, in corporate or similar environments where each >individual package installation must be approved, having at least some >timezone data in the base install ensures that all Python code can >assume the *existence* of timezone support (i

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 11, 2012, at 03:37 PM, Brandon W Maister wrote: >Barry you want github raw: >https://raw.github.com/regebro/tz-pep/master/pep-04tz.txt I found that out. I was mostly just complaining. ;) -Barry signature.asc Description: PGP signature ___ Pyt

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 11, 2012, at 03:31 PM, Barry Warsaw wrote: >I've assigned this PEP 431, reformatted a few extra wide paragraphs, committed >and pushed. Unfortunately, it looks like the online PEP updater isn't working. -Barry signature.asc Descriptio

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 11, 2012, at 04:23 PM, Lennart Regebro wrote: >A new ``is_dst`` parameter is added to several of the `tzinfo` methods to >handle time ambiguity during DST changeovers. >``None`` will raise an ``AmbiguousTimeError`` exception if the time specified >was during a DST change over. It will also

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 12, 2012, at 01:14 PM, Nick Coghlan wrote: >That's a backwards compatibility risk, though - many applications are >likely coping just fine with the slightly corrupted time values, but would >fall over if an exception was raised instead. The default should probably >be chosen so that the sin

Re: [Python-Dev] Mercurial workflow question...

On Dec 14, 2012, at 12:36 PM, Nick Coghlan wrote: >Both Git and Hg recognise there is a difference between interim commits and >ones you want to publish and provide tools to revise a series of commits >into a simpler set for publication to an official repo. One of the things I love about Bazaar i

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 14, 2012, at 12:01 PM, Christian Heimes wrote: >* It's the release managers responsibility to make sure, all final > releases contain the current db. This needs to be added to the > RM's TODO list. That would be PEP 101. -Barry ___ Python-Dev

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 20, 2012, at 11:18 AM, Ben Finney wrote: >Terry Reedy writes: > >> On 12/12/2012 10:56 AM, Lennart Regebro wrote: >> >> >> It seems like calling get_timezone() with an unknown timezone >> >> should just throw ValueError, not necessarily some custom >> >> Exception? >> > >> > That could ver

Re: [Python-Dev] PandaBoard, Raspberry Pi coming to Buildbot fleet

On Dec 20, 2012, at 02:54 PM, Trent Nelson wrote: >On Thu, Dec 20, 2012 at 10:52:56AM -0800, Trent Nelson wrote: >> I'll work on setting the ARM boards up next week. > >Does anyone have a preference regarding the operating system? There >are a bunch of choices listed here: > >

Re: [Python-Dev] [Python-checkins] Cron /home/docs/build-devguide

On Dec 22, 2012, at 03:36 PM, Terry Reedy wrote: >I always reject the requests as I don't believe these messages belong here. I >even asked, some months ago, on pydev who was responsible for the robot that >sends these but got no answer. Today, apparently, another list admin decided >on the opposi

Re: [Python-Dev] Draft PEP for time zone support.

On Dec 28, 2012, at 07:02 PM, Lennart Regebro wrote: >On Thu, Dec 20, 2012 at 5:43 PM, Barry Warsaw wrote: > >> >> That would be `class UnknownTimeZoneError(ValueError, TimeZoneError)`. >> > >As of today, in Pytz, UnknownTimeZoneError in fact subclasses KeyErro

Re: [Python-Dev] fork or exec?

On Jan 11, 2013, at 06:25 PM, Ben Leslie wrote: >Python is not UNIX, but I think if you are directly using the POSIX >interfaces they should work (more or less) the same way the would if you were >writing a C program. (Some of us still use Python to prototype things that >will later be converted

Re: [Python-Dev] BDFL delegation for PEP 426 (PyPI metadata 1.3)

On Feb 03, 2013, at 04:04 PM, Nick Coghlan wrote: >- someone else volunteers to be BDFL-Delegate for PEP 426 (MvL, perhaps?) On principle, I think it's a good idea to try to recruit another PEP czar. I'm not volunteering though, due to lack of time. Cheers, -Barry ___

Re: [Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build

On Feb 06, 2013, at 02:38 PM, Antoine Pitrou wrote: >Le Mon, 04 Feb 2013 21:04:39 +0100, >Matthias Klose a écrit : >> So what I do understand, build-related issues like an arm64 or >> mingw32 port are ok for 2.7, if they are stable on the trunk, and >> communicated on python-dev? > >Making Python

Re: [Python-Dev] _not_found attribute on ImportError

On Feb 11, 2013, at 09:23 PM, Nick Coghlan wrote: >On Mon, Feb 11, 2013 at 8:58 PM, Chris Withers wrote: >> Have any other exceptions grown new attributes in Python 3? > >Off the top of my head, ImportError grew "name" and "path" attributes >in 3.3, everything grew __cause__, __context__ and __tr

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote: >Sure, every little addition is "trivial". At the end you have a scary >monster made of many little trivial additions along the years, and >everyone has to take care not to break it. Why Antoine, that surely isn't the case with the import system

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Feb 10, 2013, at 02:34 PM, Antoine Pitrou wrote: >zope.interface has been ported to Python 3, so the annoyance can't be >very blocking. The syntax is different, but I actually prefer the Python 3-compatible syntax better. It uses a class decorator instead of a magic class attribute, so it's m

Re: [Python-Dev] Submitting PEP 422 (Simple class initialization hook) for pronouncement

On Feb 11, 2013, at 08:33 PM, Nick Coghlan wrote: >I like that. Perhaps the PEP should propose some additional guidance >in PEP 8 regarding class based metaprogramming? I wouldn't put it in PEP 8, since it'll glaze the eyes of all but 6 people on the planet. Probably better as a HOWTO in the doc

Re: [Python-Dev] checking what atexit handlers are registered in Python 3

On Feb 10, 2013, at 10:36 AM, Chris Withers wrote: >One rough edge I've hit: I see the atexit module has moved to be C-based and, >as far as I can tell, no longer allows you to introspect what atexit >functions have been registered. > >If I'm writing tests for code that registers atexit handlers,

Re: [Python-Dev] Marking GC details as CPython-only

On Feb 13, 2013, at 08:30 PM, Armin Rigo wrote: >Actually right now, at the exit of the interpreter, we just leave the >program without caring about running any __del__. This might mean >that in a short-running script no __del__ is ever run. I'd add this >question to your original list: is it go

Re: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 03:36, "Martin v. Löwis" wrote: > I mostly agree with Fredrik. What good does removal of xmllib do? > It's not that it is causing any maintenance burden, so we could just > leave it in. Whether this means that we keep xmllib until P3k, I > don't know. > > As for PEP 4: I don

RE: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 05:40, Raymond Hettinger wrote: > * The number one current python complaint is the state of the standard > library: http://www.internetnews.com/dev-news/article.php/3441931 . > Some of this may just be the fruits of AMK's highly publicized journal > entry; however, I think t

Re: [Python-Dev] Deprecated xmllib module

On Sun, 2004-12-05 at 18:49, Brett C. wrote: > And as for the mention of dropping PEP 4, I agree with the running consensus > that it isn't needed thanks to the warning module. Do we need to have a more > formal vote to drop PEP 4, or should one the PEP maintainers just delete it? There's real

RE: [Python-Dev] Deprecated xmllib module

On Mon, 2004-12-06 at 07:44, Raymond Hettinger wrote: > We are trying to remove clutter, not keep it in perpetuity. Leaving the > docs means continuing to have to test it, field bug reports, be aware of > its existence, etc. > > Do not keep this on a respirator. Let it die in peace. Old docume

Re: [Python-Dev] Rewriting PEP4

On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote: Martin, +1 on everything you wrote, with one minor quibble. > Removal > === > If the module has been deprecated for atleast a year and atleast > a version, it can be removed. Removal should move it to old-libs > for pure Python modules; a

RE: [Python-Dev] Rewriting PEP4

On Tue, 2004-12-07 at 03:12, Raymond Hettinger wrote: > I'm concerned about the old email modules. They haven't been deprecated > and may stay around for a good while. However, some SF requests have > been passed over on the basis that the modules are supplanted and will > be phased out. I don'

Freezing Python (was Re: [Python-Dev] 2.4 news reaches interesting places)

On Thu, 2004-12-09 at 10:30, Phillip J. Eby wrote: > ISTR that for a long time, Visual Basic actually did the same thing. A few > magazines mentioned the fact, but nobody really cared. However, if this is > really a concern, bundle Pyrex as well. Both Pyrex and py2exe are > distutils-based,

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places

On Sun, 2004-12-12 at 12:32, Carlos Ribeiro wrote: > For those who believe that a non-profit project should not do any > marketing, a reminder. If the perception about Python is one of a slow > language, it's much more difficult to find places where you can use > Python. In the long run, many of u

Re: [Python-Dev] Re: Re: 2.4 news reaches interesting places

On Wed, 2004-12-15 at 07:32, Nick Coghlan wrote: > about.python.org? > > And if someone ends up playing with the DNS server, maybe they could add > wiki.python.org while they're at it :) DNS changes have to go through pydotorg at python.org, since Thomas is the person currently able to add host

Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Pythonmarshal.c, 1.79, 1.80

On Mon, 2004-12-20 at 12:48, Raymond Hettinger wrote: > Perhaps a rather quick Py2.4.1 would be in order. +1 -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.o

RE: [Python-Dev] Please help complete the AST branch

On Mon, 2005-01-03 at 23:17, Tony Meyer wrote: > > Perhaps interested parties should take up the discussion on > > the compiler-sig. > > This isn't listed in the 'currently active' SIGs list on > - is it still active, or will it now be? If so, > perhaps it should be add

Re: [Python-Dev] Please help complete the AST branch

On Tue, 2005-01-04 at 11:17, Jeremy Hylton wrote: > That's fine with me. We had taken it to the compiler-sig when it > wasn't clear there was interest in the ast branch :-). Ok, then I'll leave compiler-sig where it is. -Barry signature.asc Description: This is a digitally signed message part

Re: [Python-Dev] Let's get rid of unbound methods

On Tue, 2005-01-04 at 18:01, Jack Jansen wrote: > But I'm more worried about losing the other information in an unbound > method, specifically im_class. I would guess that info is useful to > class browsers and such, or are there other ways to get at that? That would be my worry too. OTOH, we

Re: [Python-Dev] Let's get rid of unbound methods

On Wed, 2005-01-05 at 10:37, Glyph Lefkowitz wrote: > One approach I have taken in order to avoid copiously over-documenting > every super() using class is to decouple different phases of > initialization by making __init__ as simple as possible (setting a few > attributes, resisting the temptatio

Re: [Python-Dev] Let's get rid of unbound methods

On Wed, 2005-01-05 at 10:41, Glyph Lefkowitz wrote: > I think it would be reasonable to assign im_class only to functions > defined in class scope. The only serialization that would break in that > case is if your example had a 'del f' at the end. +1. If you're doing something funkier, then you

RE: [Python-Dev] Re: Subscribing to PEP updates

On Thu, 2005-01-06 at 11:33, Chermside, Michael wrote: > > Why not just subscribe to > > python-checkins and filter out everything *but* nondist/peps? > > But there are lots of people who might be interested in > following PEP updates but not other checkins. Pretty > much anyone who considers them

Re: [Python-Dev] Re: Subscribing to PEP updates

On Fri, 2005-01-07 at 10:05, Nick Coghlan wrote: > Barry Warsaw wrote: > > As an experiment, I just added a PEP topic to the python-checkins > > mailing list. You could subscribe to this list and just select the PEP > > topic (which matches the regex "PEP" in

RE: [Python-Dev] Re: Subscribing to PEP updates

On Mon, 2005-01-10 at 09:40, Michael Chermside wrote: > Barry writes: > > As an experiment, I just added a PEP topic to the python-checkins > > mailing list. You could subscribe to this list and just select the PEP > > topic (which matches the regex "PEP" in the Subject header or first few > > lin

RE: [Python-Dev] logging class submission

On Tue, 2005-01-11 at 12:58, Batista, Facundo wrote: > [Stephan Stapel] > > #- > There's a license issue here? > #- > #- I was given the advise to use this license. If this license > #- prohibts inclusion into Python, how should I re-license the code? > > I just was asking. Who gave you the ad

Re: [Python-Dev] redux: fractional seconds in strptime

On Fri, 2005-01-14 at 06:40, Alex Martelli wrote: > +1 -- I never liked the idea that 'time tuples' lost fractions of a > second. On platforms where that's sensible and not too hard, > time.time() could also -- unobtrusively and backwards compatibly -- set > that same attribute. I wonder if,

Re: [Python-Dev] Getting rid of unbound methods: patch available

On Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote: > If you want to make methods look more like functions, > the method object should become a subclass of the function > object (function + added im_* attributes). I have no personal use cases, but it does make me vaguely uncomfortable to lose im_cl

Re: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Mon, 2005-01-31 at 00:17, Guido van Rossum wrote: > > I had hoped for the core of p3k to be built for scratch [...] > > Stop right there. Phew! -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list P

RE: Moving towards Python 3.0 (was Re: [Python-Dev] Speed up function calls)

On Mon, 2005-01-31 at 00:00, Skip Montanaro wrote: > Raymond> I had hoped for the core of p3k to be built for scratch ... > > Then we should just create a new CVS module for it (or go whole hog and try > a new revision control system altogether - svn, darcs, arch, whatever). I've heard rumors

Re: [Python-Dev] Re: python/dist/src/Lib rfc822.py,1.78,1.79

On Tue, 2005-02-08 at 10:35, Guido van Rossum wrote: > This would have been caught if there was a unit test validating what > the documentation says. Why aren't there unit tests for this code? I > think we need to raise the bar for "wholistic" improvements to a > module: first write a unit test if

Re: [Python-Dev] license issues with profiler.py and md5.h/md5c.c

On Sat, 2005-02-12 at 08:37, A.M. Kuchling wrote: > The md5 module has been a standard module for a long time; making it > optional in the next version of Python isn't possible. We'd have to > require OpenSSL to compile Python. I totally agree. -Barry signature.asc Description: This is a dig

Re: [Python-Dev] UserString

On Mon, 2005-02-21 at 11:15, Guido van Rossum wrote: > Right. There are plenty of examples where LBYL is better, e.g. because > there are too many different exceptions to catch, or they occur in too > many places. One of my favorites is creating a directory if it doesn't > already exist; I always

Re: [Python-Dev] UserString

On Tue, 2005-02-22 at 11:16, Guido van Rossum wrote: > > Really? I do this kind of thing all the time: > > > > import os > > import errno > > try: > > os.makedirs(dn) > > except OSError, e: > > if e.errno <> errno.EEXIST: > > raise > > You have a lot more faith in the errno modul

Re: [Python-Dev] UserString

On Tue, 2005-02-22 at 19:14, Andrew McNamara wrote: > >> if e.errno <> errno.EEXIST: > >> raise > > > >You have a lot more faith in the errno module than I do. Are you sure > >the same error codes work on all platforms where Python works? It's > >also not exactly readable (except for ol

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