Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Aug 29, 2014, at 7:44 PM, Alex Gaynor wrote: > Disabling verification entirely externally to the program, through a CLI flag > or environment variable. I'm pretty down on this idea, the problem you hit is > that it's a pretty blunt instrument to swing, and it's almost impossible to > imagin

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sep 2, 2014, at 4:01 PM, Nick Coghlan wrote: > > On 3 Sep 2014 08:18, "Alex Gaynor" wrote: > > > > Antoine Pitrou pitrou.net> writes: > > > > > > > > And how many people are using Twisted as an HTTPS client? > > > (compared to e.g. Python's httplib, and all the third-party libraries > > >

Re: [Python-Dev] PEP 476: Enabling certificate validation by default!

On Sep 2, 2014, at 4:28 PM, Nick Coghlan wrote: > On 3 Sep 2014 09:08, "David Reid" wrote: > > > > Nick Coghlan gmail.com> writes: > > > > > Creating *new* incompatibilities between Python 2 & Python 3 is a major > > > point > > > of concern. > > > > Clearly this change should be backported t

[Python-Dev] Language Summit Follow-Up

At the language summit, Alex and I volunteered to put together some recommendations on what changes could be made to Python (the language) in order to facilitate a smoother transition from Python 2 to Python 3. One of the things that motivated this was the (surprising, to us) consideration that

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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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] 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] 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 possibly > incorporating th

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] setUpClass and setUpModule in unittest

On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote: > I have skimmed this thread (hence this reply to the first rather than > the last message), but in general I am baffled by the hostility of > testing framework developers towards their users. The arguments > against class- and module-level seUp

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

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] 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] '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] __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] __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] 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] 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] Proposing PEP 376

First: thank you distutils-sig, and especially Tarek, for spearheading this effort! I'm particularly excited about the "Distribution" object that this PEP specifies. I've been waiting for a long time to be able to load an object describing a distribution, rather than running setup.py and hopin

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] 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] 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] 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] 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 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 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 26, 2010, at 4:55 AM, Brian Quinlan wrote: > I said exactly the opposite of what I meant: futures don't need a reference > to the invoker. Indeed they don't, and they really shouldn't have one. If I wrote that they did, then it was an error. ... and that appears to be it! Thank you f

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] #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] 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] 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 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 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 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 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] 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] 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] 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] 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] 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] [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] 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] 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 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 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] [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] [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] 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] 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] 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] 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] 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] 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] 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] '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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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 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 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] 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] 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] 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] 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] 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 9:44 PM, Stephen J. Turnbull wrote: > James Y Knight writes: > >> You put a smiley, but, in all seriousness, I think that's actually >> the right thing to do if anyone writes a new programming >> language. It is clearly the right thing if you don't have to be >> concerned with

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

On Nov 24, 2010, at 4:03 AM, Stephen J. Turnbull wrote: > You end up proliferating types that all do the same kind of thing. Judicious > use of inheritance helps, but getting the fundamental abstraction right is > hard. Or least, Emacs hasn't found it in 20 years of trying. Emacs hasn't even

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

On Nov 24, 2010, at 10:55 PM, Stephen J. Turnbull wrote: > Greg Ewing writes: >> On 24/11/10 22:03, Stephen J. Turnbull wrote: >>> But >>> if you actually need to remember positions, or regions, to jump to >>> later or to communicate to other code that manipulates them, doing >>> this stuff the st

Re: [Python-Dev] Possible optimization for LOAD_FAST ?

On Jan 2, 2011, at 10:18 PM, Guido van Rossum wrote: > On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor wrote: >> No, it's singularly impossible to prove that any global load will be any >> given >> value at compile time. Any optimization based on this premise is wrong. > > True. > > My proposed

Re: [Python-Dev] Checking input range in time.asctime and time.ctime

On Jan 5, 2011, at 4:33 PM, Guido van Rossum wrote: > Shouldn't the logic be to take the current year into account? By the > time 2070 comes around, I'd expect "70" to refer to 2070, not to 1970. > In fact, I'd expect it to refer to 2070 long before 2070 comes around. > > All of which makes me t

  1   2   >