Re: [Python-Dev] OpenSSL Voluntarily (openssl-1.0.0a)

On Nov 23, 2010, at 9:02 AM, Antoine Pitrou wrote: > On Tue, 23 Nov 2010 00:07:09 -0500 > Glyph Lefkowitz wrote: >> On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < >> ocean-c...@m2.ccsnet.ne.jp> wrote: >> >>> Hello. Does this affect python? Thank yo

Re: [Python-Dev] len(chr(i)) = 2?

On Nov 23, 2010, at 7:22 PM, James Y Knight wrote: > On Nov 23, 2010, at 6:49 PM, Greg Ewing wrote: >> Maybe Python should have used UTF-8 as its internal unicode >> representation. Then people who were foolish enough to assume >> one character per string item would have their programs break >> ra

Re: [Python-Dev] constant/enum type in stdlib

On Nov 23, 2010, at 10:01 AM, Antoine Pitrou wrote: > Well, it is easy to assign range(N) to a tuple of names when desired. I > don't think an automatically-enumerating constant generator is needed. I don't think that numerical enumerations are the only kind of constants we're talking about. O

Re: [Python-Dev] constant/enum type in stdlib

On Nov 23, 2010, at 10:37 AM, ben.cottr...@nominum.com wrote: > I'd prefer not to think of the number of times I've made the following > mistake: > > s = socket.socket(socket.SOCK_DGRAM, socket.AF_INET) If it's any consolation, it's fewer than the number of times I have :). (More fun, actuall

Re: [Python-Dev] OpenSSL Voluntarily (openssl-1.0.0a)

On Mon, Nov 22, 2010 at 11:13 PM, Hirokazu Yamamoto < ocean-c...@m2.ccsnet.ne.jp> wrote: > Hello. Does this affect python? Thank you. > > http://www.openssl.org/news/secadv_20101116.txt > No. ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] Breaking undocumented API

On Nov 16, 2010, at 4:49 PM, Guido van Rossum wrote: >> PEP 8 isn't nearly visible enough, either. Whatever the rule is, it needs >> to be presented with the information itself. If the rule is that things not >> documented in the library manual have no compatibility guarantees, then all >> of t

Re: [Python-Dev] Breaking undocumented API

On Nov 10, 2010, at 2:21 PM, James Y Knight wrote: > On the other hand, if you make the primary mechanism to indicate privateness > be a leading underscore, that's obvious to everyone. +1. One of the best features of Python is the ability to make a conscious decision to break the interface of

Re: [Python-Dev] Breaking undocumented API

On Nov 8, 2010, at 4:50 PM, Guido van Rossum wrote: > On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz > wrote: >> This seems like a pretty clear case of "practicality beats purity". Not >> only has nobody complained about deprecatedModuleAttribute, but there are

Re: [Python-Dev] Breaking undocumented API

On Nov 8, 2010, at 2:35 PM, exar...@twistedmatrix.com wrote: > On 09:57 pm, br...@python.org wrote: >> On Mon, Nov 8, 2010 at 13:45, wrote: >>> On 09:25 pm, br...@python.org wrote: On Mon, Nov 8, 2010 at 13:03, wrote: > > On 07:58 pm, br...@python.org wrote: >>> >

Re: [Python-Dev] Pickle alternative in stdlib (Was: On breaking modules into packages)

On Nov 4, 2010, at 12:49 PM, Guido van Rossum wrote: > What's the attack you're thinking of on marshal? It never executes any > code while unmarshalling (although it can unmarshal code objects -- > but the receiving program has to do something additionally to execute > those). These issues may h

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Nov 3, 2010, at 11:26 AM, Alexander Belopolsky wrote: > This may not be a problem for smart tools, but for me and a simple > editor what used to be: Maybe this is the real problem? It's 2010, we should all be far enough beyond EDLIN that our editors can jump to the definition of a Python c

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Nov 3, 2010, at 1:04 PM, James Y Knight wrote: > This is the strongest reason why I recommend to everyone I know that they not > use pickle for storage they'd like to keep working after upgrades [not just > of stdlib, but other 3rd party software or their own software]. :) +1. Twisted actu

Re: [Python-Dev] closing files and sockets in a timely manner in the stdlib

On Oct 30, 2010, at 2:39 PM, Jack Diederich wrote: > On Fri, Oct 29, 2010 at 8:35 PM, Brett Cannon wrote: >> For those of you who have not noticed, Antoine committed a patch that >> raises a ResourceWarning under a pydebug build if a file or socket is >> closed through garbage collection instead

Re: [Python-Dev] Continuing 2.x

On Oct 28, 2010, at 10:51 PM, Brett Cannon wrote: > I think people need to stop viewing the difference between Python 2.7 > and Python 3.2 as this crazy shift and view it from python-dev's > perspective; it should be viewed one follows from the other at this > point. You can view it as Python 3.2

Re: [Python-Dev] Support for async read/write

On Oct 20, 2010, at 12:31 AM, Jeffrey Yasskin wrote: > No comment on the rest of your claim, but this is a silly argument. > The standard says the same thing about at least fcntl.h, signal.h, > pthread.h, and ucontext.h, which clearly are useful. It was meant to be tongue-in-cheek :). Perhaps I

Re: [Python-Dev] Support for async read/write

On Oct 19, 2010, at 9:55 PM, exar...@twistedmatrix.com wrote: >> Not only is the performance usually worse than expected, the behavior of >> aio_* functions require all kinds of subtle and mysterious coordination with >> signal handling, which I'm not entirely sure Python would even be able to

Re: [Python-Dev] Support for async read/write

On Oct 19, 2010, at 8:09 PM, James Y Knight wrote: > There's a difference. > > os._exit is useful. os.open is useful. aio_* are *not* useful. For anything. > If there's anything you think you want to use them for, you're wrong. It > either won't work properly or it will worse performing than t

Re: [Python-Dev] Supporting raw bytes data in urllib.parse.* (was Re: Polymorphic best practices)

On Sep 18, 2010, at 10:18 PM, Steve Holden wrote: >> I could probably be persuaded to merge the APIs, but the email6 >> precedent suggests to me that separating the APIs better reflects the >> mental model we're trying to encourage in programmers manipulating >> text (i.e. the difference between t

Re: [Python-Dev] Polymorphic best practices [was: (Not) delaying the 3.2 release]

On Sep 16, 2010, at 7:34 PM, Barry Warsaw wrote: > On Sep 16, 2010, at 06:11 PM, Glyph Lefkowitz wrote: > >> That may be a handy way to deal with some grotty internal >> implementation details, but having a 'decode()' method is broken. The >> thing I care ab

Re: [Python-Dev] Polymorphic best practices [was: (Not) delaying the 3.2 release]

On Sep 16, 2010, at 4:51 PM, R. David Murray wrote: > Given a message, there are many times you want to serialize it as text > (for example, for presentation in a UI). You could provide alternate > serialization methods to get text out on demandbut then what if > someone wants to push that te

Re: [Python-Dev] Garbage announcement printed on interpreter shutdown

On Sep 10, 2010, at 5:10 PM, Amaury Forgeot d'Arc wrote: > 2010/9/10 Fred Drake : >> On Fri, Sep 10, 2010 at 4:32 PM, Georg Brandl wrote: >>> IMO this runs contrary to the decision we made when DeprecationWarnings were >>> made silent by default: it spews messages not only at developers, but als

Re: [Python-Dev] Internal counter to debug leaking file descriptors

On Aug 31, 2010, at 10:03 AM, Guido van Rossum wrote: > On Linux you can look somewhere in /proc, but I don't know that it > would help you find where a file was opened. "/dev/fd" is actually a somewhat portable way of getting this information. I don't think it's part of a standard, but on Lin

Re: [Python-Dev] 'hasattr' is broken by design

On Aug 24, 2010, at 8:31 AM, Benjamin Peterson wrote: > 2010/8/24 Hrvoje Niksic : >> The __length_hint__ lookup expects either no exception or AttributeError, >> and will propagate others. I'm not sure if this is a bug. On the one hand, >> throwing anything except AttributeError from __getattr_

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

On Aug 12, 2010, at 6:30 AM, Tim Golden wrote: > I don't care how many stats we're doing You might not, but I certainly do. And I can guarantee you that the authors of command-line tools that have to start up in under ten seconds, for example 'bzr', care too.

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Aug 3, 2010, at 4:28 AM, M.-A. Lemburg wrote: > I don't think that's a problem: the SQLite database would be a cache > like e.g. a font cache or TCSH command cache, not a replacement of > the meta files stored in directories. > > Such a database would solve many things at once: faster access

Re: [Python-Dev] PEP 376 proposed changes for basic plugins support

On Aug 2, 2010, at 9:53 AM, exar...@twistedmatrix.com wrote: > On 01:27 pm, m...@egenix.com wrote: >> exar...@twistedmatrix.com wrote: >>> On 12:21 pm, m...@egenix.com wrote: See Zope for an example of how well this simply mechanism works out in practice: it simply scans the "Prod

Re: [Python-Dev] proto-pep: plugin proposal (for unittest)

On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote: > > On 1 Aug, 2010, at 17:22, Éric Araujo wrote: > >>> Speaking of which... Your documentation says it's named ~/unittest.cfg, >>> could you make this a file in the user base (that is, the prefix where >>> 'setup.py install --user' will install

Re: [Python-Dev] Python signal processing question

On Jul 22, 2010, at 12:00 AM, Stephen J. Turnbull wrote: > My understanding of OSError is that the OS is saying "sorry, what you > tried to do is perfectly reasonable under some circumstances, but you > can't do that now." ENOMEM, EPERM, ENOENT etc fit this model. > > RuntimeError OTOH is basica

Re: [Python-Dev] What to do with languishing patches?

On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: > We already have "posponed" and "remind" resolutions, but these are > exclusive of "accepted". I think there should be a clear way to mark > the issue "accepted and would be applied if X.Y was out already." > Chances are one of the resol

Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module

On Jul 13, 2010, at 5:02 PM, Nick Coghlan wrote: > My concerns aren't about a module reimporting itself directly, they're > about the case where a utility module is invoked as __main__ but is > also imported normally somewhere else in a program (e.g. pdb is > invoked as a top-level debugger, but i

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On Jul 12, 2010, at 5:47 PM, Fred Drake wrote: > On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord > wrote: >> I'm sure Brett will love this idea, but if it was impossible to reimport the >> script being executed as __main__ with a different name it would solve these >> problems. > > Indeed! And

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On Jul 12, 2010, at 11:36 AM, Reid Kleckner wrote: > (Somwhat off-topic): Another pain point students had was accidentally > shadowing stdlib modules, like random. Renaming the file didn't solve > the problem either, because it left behind .pycs, which I had to help > them delete. I feel your

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 12, 2010, at 4:34 AM, Éric Araujo wrote: >> Plus, is a useful resource >> for core developers with only a little bit of free time to do a >> review. > > Title: “Review Tickets, By Order You Should Review Them In” > I haven’t found a description of

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 5:33 PM, Georg Brandl wrote: > Honestly, how would you feel as a committer to have scores of issues assigned > to you -- as a consequence of speedy triage -- knowing that you have to invest > potentially hours of volunteer time into them, while the person doing the > triaging i

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 3:19 PM, Martin v. Löwis wrote: > Unfortunately, it's often not clear what the submitter wants: does she > want to help, or want to get help? For a bug report, I often post a > message "can you provide a patch?", but sometimes, it isn't that clear. Perhaps this is the one area

Re: [Python-Dev] Removing IDLE from the standard library

On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote: >> Initially (five years ago!) I tried to overcome these issues by >> improving IDLE, solving problems and adding a few key features. >> Without going into details, suffice to say that IDLE hasn't improved >> much since 2005 despite my efforts.

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library

On Jul 11, 2010, at 10:22 AM, Tal Einat wrote: > Most of the responses up to this point have been strongly against my > proposal. The main reason given is that it is nice to have a graphical > IDE supported out-of-the-box with almost any Python installation. This > is especially important for nov

Re: [Python-Dev] Licensing // PSF // Motion of non-confidence

On Jul 6, 2010, at 8:09 AM, Steven D'Aprano wrote: > You've never used Apple's much-missed Hypertalk, have you? :) on mailingListMessage get the message put it into aMessage if the thread of aMessage contains license wankery put aMessage into the trash

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

On Jul 2, 2010, at 12:28 AM, Steven D'Aprano wrote: > This question was inspired by something asked on #python today. Consider > it a hypothetical, not a serious proposal. > > We know that many semantic errors in Python lead to runtime errors, e.g. > 1 + "1". If an implementation rejected them

Re: [Python-Dev] thoughts on the bytes/string discussion

On Jun 25, 2010, at 5:02 PM, Guido van Rossum wrote: > But you'd still have to validate it, right? You wouldn't want to go on > using what you thought was wrapped UTF-8 if it wasn't actually valid > UTF-8 (or you'd be worse off than in Python 2). So you're really just > worried about space consum

Re: [Python-Dev] thoughts on the bytes/string discussion

On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote: > Regarding the proposal of a String ABC, I hope this isn't going to > become a backdoor to reintroduce the Python 2 madness of allowing > equivalency between text and bytes for *some* strings of bytes and not > others. For my part, what I wan

Re: [Python-Dev] email package status in 3.X

On Jun 23, 2010, at 8:17 AM, Steve Holden wrote: > Guido van Rossum wrote: >> On Tue, Jun 22, 2010 at 9:37 AM, Tres Seaver wrote: >>> Any "turdiness" (which I am *not* arguing for) is a natural consequence >>> of the kinds of backward incompatibilities which were *not* ruled out >>> for Python 3

Re: [Python-Dev] bytes / unicode

On Jun 22, 2010, at 8:57 PM, Robert Collins wrote: > bzr has a cache of decoded strings in it precisely because decode is > slow. We accept slowness encoding to the users locale because thats > typically much less data to examine than we've examined while > generating the commit/diff/whatever. We

Re: [Python-Dev] bytes / unicode

On Jun 22, 2010, at 7:23 PM, Ian Bicking wrote: > This is a place where bytes+encoding might also have some benefit. XML is > someplace where you might load a bunch of data but only touch a little bit of > it, and the amount of data is frequently large enough that the efficiencies > are impor

Re: [Python-Dev] bytes / unicode

On Jun 22, 2010, at 2:07 PM, James Y Knight wrote: > Yeah. This is a real issue I have with the direction Python3 went: it pushes > you into decoding everything to unicode early, even when you don't care -- > all you really wanted to do is pass it from one API to another, with some > well-defi

Re: [Python-Dev] bytes / unicode

On Jun 22, 2010, at 12:53 PM, Guido van Rossum wrote: > On Mon, Jun 21, 2010 at 11:47 PM, Raymond Hettinger > wrote: >> >> On Jun 21, 2010, at 10:31 PM, Glyph Lefkowitz wrote: >> >> This is a common pain-point for porting software to 3.x - you had a >> stri

Re: [Python-Dev] bytes / unicode

On Jun 21, 2010, at 10:58 PM, Stephen J. Turnbull wrote: > The RFC says that URIs are text, and therefore they can (and IMO > should) be operated on as text in the stdlib. No, *blue* is the best color for a shed. Oops, wait, let me try that again. While I broadly agree with this statement, it

Re: [Python-Dev] bytes / unicode

On Jun 21, 2010, at 2:17 PM, P.J. Eby wrote: > One issue I remember from my "enterprise" days is some of the Asian-language > developers at NTT/Verio explaining to me that unicode doesn't actually solve > certain issues -- that there are use cases where you really *do* need "bytes > plus encodi

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)

On Jun 19, 2010, at 5:39 PM, geremy condra wrote: > Bottom line, what I'd really like to do is kick them all off of #python, but > practically I see very little that can be done to rectify the situation at > this > point. Here's something you can do: port libraries to python 3 and make the ecosy

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)

On Jun 19, 2010, at 5:02 PM, Terry Reedy wrote: > HoweverI have very little experience with IRC and consequently have little > idea what getting a permanent, owned, channel like #python entails. Hence the > '?' that follows. > > What do others think? Sure, this is a good idea. Technically spe

Re: [Python-Dev] PEP 3148 ready for pronouncement

to be it! Thank you for your very gracious handling of a pretty huge pile of criticism :). Good luck with the PEP, -glyph ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://ma

Re: [Python-Dev] PEP 3148 ready for pronouncement

On May 26, 2010, at 3:37 AM, Paul Moore wrote: > On 26 May 2010 08:11, Lennart Regebro wrote: >> On Wed, May 26, 2010 at 06:22, Nick Coghlan wrote: >>> - download a futures module from PyPI and live with the additional >>> dependency >> >> Why would that be a problem? > > That has been hashed

Re: [Python-Dev] PEP 3148 ready for pronouncement

On May 24, 2010, at 5:36 AM, Brian Quinlan wrote: > On May 24, 2010, at 5:16 AM, Glyph Lefkowitz wrote: >> On May 23, 2010, at 2:37 AM, Brian Quinlan wrote: >>> On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote: > ProcessPoolExecutor has the same serialization perils

Re: [Python-Dev] PEP 3148 ready for pronouncement

On May 23, 2010, at 2:37 AM, Brian Quinlan wrote: > On May 23, 2010, at 2:44 PM, Glyph Lefkowitz wrote: > >> >> On May 22, 2010, at 8:47 PM, Brian Quinlan wrote: >> >>> Jesse, the designated pronouncer for this PEP, has decided to keep >>> discus

Re: [Python-Dev] PEP 3148 ready for pronouncement

On May 22, 2010, at 8:47 PM, Brian Quinlan wrote: > Jesse, the designated pronouncer for this PEP, has decided to keep discussion > open for a few more days. > > So fire away! As you wish! The PEP should be consistent in its usage of terminology about callables. It alternately calls them "c

Re: [Python-Dev] configuring the buildbot to skip some tests?

On May 13, 2010, at 9:41 AM, exar...@twistedmatrix.com wrote: > On 03:17 am, jans...@parc.com wrote: >> I've got parc-tiger-1 up and running again. It's failing on test_tk, >> which makes sense, because it's running as a background twisted process, >> and thus can't access the window server. I

Re: [Python-Dev] patch for review: __import__ documentation

On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote: > I see the confusion. I think Martin meant more about open issues that > required discussion, not simply issues that had a patch ready to go. Ach. I hit 'send' too soon. I also wanted to say: it seemed quite clear to me that Martin specifical

Re: [Python-Dev] patch for review: __import__ documentation

On Apr 14, 2010, at 5:19 PM, Brett Cannon wrote: > I see the confusion. I think Martin meant more about open issues that > required discussion, not simply issues that had a patch ready to go. I'm curious - if one isn't supposed to ping the mailing list every time, how does one ask the tracker "

Re: [Python-Dev] Proposing PEP 376

e_users to inspect other Python installations or virtualenvs) it could be called active_distributions_using_path. Thanks again to the PEP's author and many contributors, -glyph ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Catch SIGINT at Python startup

On Mar 8, 2010, at 4:06 PM, Guido van Rossum wrote: > I am trying to remember why I made site.py failures non-fatal in the > first place. I don't have any specific recollection but it must've > been either from before the separation between site.py (part of the > stdlib) and sitecustomize.py (sit

Re: [Python-Dev] doctest, unicode repr, and 2to3

On Mar 4, 2010, at 11:30 PM, Barry Warsaw wrote: > If you really want to test that it's a unicode, shouldn't you actually test > its type? (I'm not sure what would happen with that under 2to3.) Presumably 2to3 will be smart enough to translate 'unicode' to 'str' and 'bytes' to... 'bytes'. Jus

Re: [Python-Dev] __file__ and bytecode-only

On Mar 3, 2010, at 10:22 PM, Greg Ewing wrote: > Glenn Linderman wrote: > >> In this scenario, the .pyc files would still live in __pycache__ ? Complete >> with the foo..pyc naming ? > > It might be neater to have a separate cache directory > for each bytecode version, named __cache.__ or > s

Re: [Python-Dev] __file__

On Feb 27, 2010, at 9:38 AM, Nick Coghlan wrote: > I do like the idea of pulling .pyc only imports out into a separate > importer, but would go so far as to suggest keeping them as a command > line option rather than as a separately distributed module. One advantage of doing this as a separately

Re: [Python-Dev] 'languishing' status for the tracker

On Feb 22, 2010, at 12:17 AM, R. David Murray wrote: > To expand on this: the desire for this arises from the observation > that we have a lot of bugs in the tracker that we don't want to close, > because they are real bugs or non-crazy enhancement requests, but for > one reason or another (lack

Re: [Python-Dev] Platform extension for distutils on other interpreters than CPython

On Feb 23, 2010, at 2:10 PM, Tarek Ziadé wrote: > On Tue, Feb 23, 2010 at 1:50 PM, Maciej Fijalkowski wrote: >> Hello. >> >> I would like to have a feature on platform module (or sys or >> somewhere) that can tell distutils or distutils2 that this platform >> (be it PyPy or Jython) is not able

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Feb 15, 2010, at 3:50 PM, Michael Foord wrote: > On 15/02/2010 20:27, Glyph Lefkowitz wrote: >> >> >> On Feb 13, 2010, at 12:46 PM, Guido van Rossum wrote: >> >>> On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz >>> wrote: >>>> I

Re: [Python-Dev] setUpClass and setUpModule in unittest

On Feb 13, 2010, at 12:46 PM, Guido van Rossum wrote: > On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz > wrote: >> On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote: >> >> For what it's worth, I am a big fan of abusing test frameworks in generally, >>

Re: [Python-Dev] setUpClass and setUpModule in unittest

modules, inheritance doesn't create an additional module object to hold on to. testresources very neatly sidesteps this problem by just providing an API to say "this test case depends on that test resource", without relying on the grouping of tests within classes, modules, or package

Re: [Python-Dev] Executing zipfiles and directories (was Re: PyCon Keynote)

On Jan 26, 2010, at 3:20 PM, Ian Bicking wrote: > Sadly you can't then do: > > chmod +x mz.py > ./mz.py Unless I missed some subtlety earlier in the conversation, yes you can :). > because it doesn't have "#!/usr/bin/env python" like typical executable > Python scripts have. You can put t

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Jan 21, 2010, at 6:48 PM, Collin Winter wrote: > Hey Glyph, > There's been a recent thread on our mailing list about a patch that > dramatically reduces the memory footprint of multiprocess concurrency > by separating reference counts from objects. We're looking at po

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

On Jan 21, 2010, at 7:25 AM, Antoine Pitrou wrote: >> We seek guidance from the community on >> an acceptable level of increased memory usage. > > I think a 10-20% increase would be acceptable. It would be hard for me to put an exact number on what I would find acceptable, but I was really hop

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

On Jan 7, 2010, at 11:21 PM, Guido van Rossum wrote: > On Thu, Jan 7, 2010 at 7:34 PM, Glyph Lefkowitz > wrote: >> >> On Jan 7, 2010, at 7:52 PM, Guido van Rossum wrote: >>> >>> I'm a little hesitant about this. First of all, UTF-8 + BOM is crazy &g

Re: [Python-Dev] Improve open() to support reading file starting with an unicode BOM

On Jan 7, 2010, at 7:52 PM, Guido van Rossum wrote: > On Thu, Jan 7, 2010 at 4:10 PM, Victor Stinner > wrote: >> Hi, >> >> Builtin open() function is unable to open an UTF-16/32 file starting with a >> BOM if the encoding is not specified (raise an unicode error). For an UTF-8 >> file starting

Re: [Python-Dev] Suggestion: new 3 release with backwards compatibility

On Jan 5, 2010, at 2:00 PM, Ian Bicking wrote: > It's not even that easy -- libraries can't apply patches for Python 3 > compatibility as they usually break Python 2 compatibility. Potentially > libraries could apply patches that make a codebase 2to3 ready, but from what > I've seen that's mor

Re: [Python-Dev] First draft of "sysconfig"

On Dec 23, 2009, at 10:00 AM, Frank Wierzbicki wrote: > On Mon, Dec 14, 2009 at 5:58 PM, Tarek Ziadé wrote: >> and for Linux and al, I am not sure but maybe a prefix for >> Jython/etc.. could be used >> for all paths. >> >> ~/.locale/lib/python/2.6/site-packages/... >> ~/.locale/jython/lib/pyth

Re: [Python-Dev] [issue1644818] Allow importing built-in submodules

On Dec 19, 2009, at 5:29 AM, Julien Danjou wrote: > Well, that's disapointing. I work on several other free software > projects, and my time is really scarce too. > > I understand blackmailing me to close a bug can be seen as a nice game. > Honestly, if I had more time to get involve in that are

Re: [Python-Dev] PEP 3003 - Python Language Moratorium

On Nov 6, 2009, at 4:52 PM, exar...@twistedmatrix.com wrote: On 09:48 pm, rdmur...@bitdance.com wrote: On Fri, 6 Nov 2009 at 15:48, Glyph Lefkowitz wrote: Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better wou

Re: [Python-Dev] Status of the Buildbot fleet and related bugs

On Nov 6, 2009, at 6:34 PM, Georg Brandl wrote: R. David Murray schrieb: So, overall I think the buildbot fleet is in good shape, and if we can nail issue 6748 I think it will be back to being an important resource for sanity checking our checkins. Yay! Thanks to all of you! Indeed! It's

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

On Nov 3, 2009, at 6:23 AM, Paul Moore wrote: 2009/11/3 Raymond Hettinger : In all these matters, I think the users should get a vote. And that vote should be cast with their decision to stay with 2.x, or switch to 3.x, or try to support both. We should not muck with their rational decis

Re: [Python-Dev] 2.7 Release? 2.7 == last of the 2.x line?

On Nov 3, 2009, at 5:16 PM, Paul Moore wrote: 2009/11/3 Brett Cannon : I'm afraid there is some FUD going around here, which is understandable since no one wants to burn a ton of time on something that will be difficult or take a lot of time. But I have not heard anyone in this email thread (or

Re: [Python-Dev] Possible language summit topic: buildbots

On Oct 25, 2009, at 3:06 PM, Martin v. Löwis wrote: (*) it may help if Buildbot would create a Win32 job object, and then use TerminateJobObject. Contributions are welcome. Some work has already been done on this, but it needs help. At the root it's a Twisted issue: http://twistedmatr

Re: [Python-Dev] Better module shutdown procedure

On Wed, Oct 14, 2009 at 2:45 PM, Neil Schemenauer wrote: > On Wed, Oct 14, 2009 at 08:35:28PM -, exar...@twistedmatrix.com wrote: > > I notice that the patch doesn't include any unit tests for the feature > > being provided > > That's hard to do although I suppose not impossible. We would be

Re: [Python-Dev] Backport new float repr to Python 2.7?

On Sun, Oct 11, 2009 at 5:16 PM, Brett Cannon wrote: > On Sun, Oct 11, 2009 at 13:00, Glyph Lefkowitz wrote: > >> The carrots I'm interested in as a user are new possibilties, like new >> standard library features, a better debugger/profiler, or everybody's &g

Re: [Python-Dev] Backport new float repr to Python 2.7?

On Sun, Oct 11, 2009 at 3:48 PM, Guido van Rossum wrote: > I'm -0 -- mostly because of the 3rd party doctests and perhaps also > because I'd like 3.x to have some carrots. (I've heard from at least > one author who is very happy with 3.x for the next edition of his > "programming for beginners"

Re: [Python-Dev] PEP 3144 review.

On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum wrote: > On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou > wrote: > > You say it yourself : it describes "the ip address/prefix of a NIC". > > It isn't the job of a Network class. A Network shouldn't describe a > > host, or a particular NIC. > >

Re: [Python-Dev] how important is setting co_filename for a module being imported to what __file__ is set to?

On Sun, Aug 30, 2009 at 8:26 PM, Guido van Rossum wrote: > On Sun, Aug 30, 2009 at 5:23 PM, Brett Cannon wrote: > > Right; the code object would think it was loaded from the original > > location it was created at instead of where it actually is. Now why > > someone would want to move their .pyc

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

On Wed, Aug 19, 2009 at 4:45 PM, "Martin v. Löwis" wrote: > > No, I just said its conventionally used as that but its not definition > > of a broadcast (in fact you can have any valid host address defined > > as broadcast as long as all members of the network agree on that) > > You could, but then

Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library

On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith wrote: > I think using .network and .broadcast are pretty well understood to be the > [0] and [-1] of the network address block. I don't think we want to start > creating new terms or access patterns here. > > +1 on leaving .network and .broadcast as-i

Re: [Python-Dev] standard library mimetypes module pathologically broken?

On Sun, Aug 2, 2009 at 4:17 PM, Jacob Rus wrote: > Robert Lehmann wrote: > > Jacob Rus wrote: > >> Here is a somewhat more substantively changed version. This one does > >> away with the 'inited' flag and the 'init' function, which might be > >> impossible given that their documented (though I wo

Re: [Python-Dev] Implementing File Modes

On Mon, Jul 27, 2009 at 3:04 PM, Paul Moore wrote: > I like MRAB's idea of using a (non-standard) "e" flag to include > stderr. So "r" reads from stdout, "re" reads from stdout+stderr. > > Anything more complicated probably should just use "raw" Popen > objects. Don't overcomplicate the interface

Re: [Python-Dev] command line attachable debugger

On Fri, Jul 24, 2009 at 9:43 PM, Edward Peschko wrote: > There should be a standard mechanism for debuggers to talk to a python > process; not one-offs for each debugger, probably at the level of the > python executable (the same way that gcc lets gdb attach with a pid.. > Sounds like this is m

Re: [Python-Dev] PEP 376 - Open questions

On 03:28 am, e...@trueblade.com wrote: Eventually, I'd like PEP 376 to support system packagers too. So for example, if you did "apt-get install python-pyqt4", then running "pip install python-pyqt4" should return without installing anything .. as RECORD will be part of the .deb previously inst

Re: [Python-Dev] PEP 376 - Open questions

On 02:55 am, e...@trueblade.com wrote: I really don't get this use case of multiple installers trying to install the same package. There's just no way that running "yum install twisted" and "apt-get install twisted" and "pip install twisted" are going to coexist with each other. The best they c

Re: [Python-Dev] draft pep: backwards compatibility

On 19 Jun, 09:08 pm, benja...@python.org wrote: 2009/6/19 : On 02:09 pm, benja...@python.org wrote: 2009/6/19 �: �What about side-effects, or exceptional conditions? �What about interactions with subclasses?  (Changing a class in a library from old-style to new-style has serious re

Re: [Python-Dev] draft pep: backwards compatibility

On 07:06 pm, pyt...@rcn.com wrote: Not sure why we need yet another pep on the subject. Just update PEP 5 if needed. Hmm. This is a good point; it might make sense to have a more specific PEP for library compatibility as opposed to language compatibility though, since language compatibility

Re: [Python-Dev] draft pep: backwards compatibility

On 02:09 pm, benja...@python.org wrote: 2009/6/19 : On 02:17 am, benja...@python.org wrote: I've taken a stab at this myself in the past while defining a policy for Twisted Yes, that's helpful. Thanks. Glad you found it useful. The questions that follow might seem satirical or parodi

Re: [Python-Dev] draft pep: backwards compatibility

On 11:13 am, fuzzy...@voidspace.org.uk wrote: Just to note that Twisted (along with Bazaar) are one of the few 'good citizens' in the Python community running their tests on Python trunk. Both projects have caught incompatibilities *before* release of new versions which is greatly preferable to

Re: [Python-Dev] draft pep: backwards compatibility

On 11:11 am, solip...@pitrou.net wrote: divmod.com> writes: This is a false dichotomy; for core developers, the list needs to be exhaustive. Everything that can change needs to be described as either compatible or incompatible. How do you enumerate "everything that can change"? It does n

Re: [Python-Dev] draft pep: backwards compatibility

On 09:21 am, solip...@pitrou.net wrote: divmod.com> writes: In order for any changes to be possible, there needs to be a clearly labeled mine-field: don't touch or depend on these things in your Python application or it *will* break every time Python is released. I think the "frozen area"

Re: [Python-Dev] draft pep: backwards compatibility

On 02:17 am, benja...@python.org wrote: Backwards compatibility seems to be an issue that arises a lot here. I think we all have an idea of it is, but we need some hard place to point to. So here's my attempt: PEP: 387 Title: Backwards Compatibility Policy Thanks for getting started on this

<    1   2   3   4   5   >