[Python-Dev] In case you're wondering about 3.5.10rc1

It's held up on SSL.  Ubuntu 20.04 changed some security parameter tunings, which breaks some uses of the SSL module, and approximately eight modules in the test suite.  I assume this wasn't caught on the buildbots because they don't use Ubuntu--or at least not a build that fresh.  SSL and t

[Python-Dev] Re: In case you're wondering about 3.5.10rc1

Python 3.5.9 has the same problems on Ubuntu 20.04 as 3.5.10. //arry/ On 7/4/20 4:53 AM, Antoine Pitrou wrote: On Sat, 4 Jul 2020 13:16:50 +0200 Antoine Pitrou wrote: On Sat, 4 Jul 2020 00:01:56 -0700 Larry Hastings wrote: It's held up on SSL.  Ubuntu 20.04 changed some sec

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/8/20 8:02 AM, Guido van Rossum wrote: Regarding the syntax for wildcards and OR patterns, the PEP explains why `_` and `|` are the best choices here: no other language surveyed uses anything but `_` for wildcards, and the vast majority uses `|` for OR patterns.  A similar argument applies t

[Python-Dev] Re: Python-Dev Digest, Vol 204, Issue 75

On 7/12/20 2:38 AM, Federico Salerno wrote: Was anything beside _ and ... proposed? Yes, the PEP mentions using '?'.  It isn't the authors' first choice but it seems they're not dead-set against it either. Personally I prefer it to special-casing '_'.  It has no meaning in Python syntax yet,

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/12/20 9:04 AM, Daniel Moisset wrote: The existing implementation has optimizations here.  If that's important, we could achieve the same result with a little dataflow analysis to optimize away the dead store.  We could even special-case optimizing away dead stores /only/ to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/12/20 3:20 PM, Guido van Rossum wrote: On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings <mailto:la...@hastings.org>> wrote: Having thought about it some, I propose it'd be acceptable to do dead store optimization if-and-only-if optimizations are explicitly enab

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/30/20 4:31 PM, Caleb Donovick wrote: However if the capture was explicit and any valid target could be used as a capture variable then I could express this cleanly: |def update_point_3d(p: Point3d, pt): match pt: case (p.x=, p.y=): pass case Point2d(p.x=, p.y=): pass ... | I like this p

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 7/31/20 12:36 AM, Tobias Kohn wrote: And since pattern matching is really a new feature to be introduced to Python, a feature that can be seen in different lights, there is no 'Python-Programmer intuition' that would apply in this case. It's not fair to say "intuition doesn't apply because

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

ted pattern matching later in their evolution. Cheers, Luciano > > Cheers, > Tobias > > P.S. Please excuse my late reply; I am currently on vacation. > > > > Quoting Larry Hastings mailto:la...@hastings.org>>: > > &

[Python-Dev] [RELEASED] Python 3.5.10rc1 is released

On behalf of the Python development community, I'm pleased to finally announce the availability of Python 3.5.10rc1. Python 3.5 is in "security fixes only" mode.  This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. Important Notice: T

[Python-Dev] Re: PEP 515: Non-empty return statement

I bet you meant PEP 525.  PEP 515 is underscores in numeric literals. And... I thought an empty "return" was equivalent to "return None"? //arry/ On 8/24/20 4:20 PM, Paul Bryan wrote: Per PEP 515: It is aSyntaxErrorto have a non-emptyreturnstatement in an asynchronous generator. Synchron

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

chniques you mention. The answer to this is that we are doubtful that it will be easy to implement them in a fully backwards compatible way (and you'd be surprised how important backwards compatibility is). The only thing I personally know about this topic is that Larry Hastings attempted

[Python-Dev] Re: Deferred, coalescing, and other very recent reference counting optimization

On 9/2/20 8:50 PM, Jim J. Jewett wrote: I suspect that splitting the reference count away from the object itself could also be profitable, as it means the cache won't have to be dirtied (and flushed) on read access, and can keep Copy-On-Write from duplicating pages. I had a patch from Thomas

[Python-Dev] [RELEASED] Python 3.5.10 is released

On behalf of the Python development community, I'm plesed to announce the availability of Python 3.5.10. Python 3.5 is in "security fixes only" mode.  This new version only contains security fixes, not conventional bug fixes, and it is a source-only release. Important Notice: The latest re

[Python-Dev] Farewell, Python 3.5

At last!  Python 3.5 has now officially reached its end-of-life. Since there have been no checkins or PRs since I tagged 3.5.10, 3.5.10 will stand as the final release in the 3.5 series. As with a similar announcement I wrote about eighteen months ago, I know we can all look back fondly on P

[Python-Dev] Re: [python-committers] Thank you Larry Hastings!

Thank you to the PSC and everybody else for your nice thoughts and kind words.  Glad to have helped out! Best wishes, //arry/ On 10/5/20 11:38 AM, Barry Warsaw wrote: They say being a Python Release Manager is a thankless job, so the Python Secret Underground (PSU), which emphatically doe

[Python-Dev] Re: Changing Python's string search algorithms

On 10/13/20 9:54 AM, Tim Peters wrote: Due to the natures of the old and new algorithms, neither will be faster or slower in all cases, the newer one should never be dramatically slower than the old one, the new one will be spectacularly faster in some cases, and "in general" it seems impossible

[Python-Dev] Let's update CObject API so it is safe and regular!

The CObject API has two flaws. First, there is no usable type safety mechanism. You can store a void *object, and a void *description. There is no established schema for the description; it could be an integer cast to a pointer, or it could point to memory of any configuration, or it could be

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Brett Cannon wrote: On Tue, Mar 31, 2009 at 20:34, Guido van Rossum > wrote: Can you get Jim Fulton's feedback? ISTR he originated this. I thought Neal started this idea? The earliest revision spotted in "svn blame cobject.[ch]" is 5782: svn log -r 5782 -

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Kristján Valur Jónsson wrote: What are the semantics of the "type" argument for PyCObject_FromVoidPtr()? From the patch, from the documentation comment above the prototype for PyCObject_FromVoidPtr() in Include/cobject.h: The "type" string must point to a legal C string of non-zero len

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Jim Fulton wrote: The only type-safety mechanism for a CObject is it's identity. If you want to make sure you're using the foomodule api, make sure the address of the CObject is the same as the address of the api object exported by the module. That doesn't help. Here's a program that crashes

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: This is a bug in cPickle. It calls the PycString_IMPORT macro at the very end of its init_stuff() function without checking for success. The bug you cite is a genuine bug, but that's not what I'm exploiting. % python >>> import _socket >>> _socket.CAPI The PyCObje

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: Yeah, any two CAPI objects can be used to play this trick, as long as you have some place that calls them. :-( FWIW, I can't take credit for this observation. Neal Norwitz threw me at this class of problem at the Py3k sprints in August 2007 at Google Mountain View, s

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: On Thu, Apr 2, 2009 at 6:22 AM, Jim Fulton wrote: The original use case for CObjects was to export an API from a module, in which case, you'd be importing the API from the module. I consider this the *only* use case. What other use cases are there? Exporting a

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Hrvoje Niksic wrote: If we're adding type information, then please make it a Python object rather than a C string. That way the creator and the consumer can use a richer API to query the "type", such as by calling its methods or by inspecting it in some other way. I'm not writing my patch t

Re: [Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum wrote: OK, my proposal would be to agree on the value of this string too: "module.variable". That's a fine idea for cases where the CObject is stored as an attribute of a module; my next update of my patch will change the existing uses to use that format. Why would you

[Python-Dev] CObject take 2: Introducing the "Capsule"

(See my posting "Let's update CObject API so it is safe and regular!" from 2009/03/31 for "take 1"). I discussed this off-list with GvR. He was primarily concerned with fixing the passing-around-a-vtable C API usage of CObject, but he wanted to preserve as much backwards compatibility as po

[Python-Dev] Proposed: add an environment variable, PYTHONPREFIXES

I've submitted a patch to implement a new environment variable, PYTHONPREFIXES. The patch is here: http://bugs.python.org/issue5819 PYTHONPREFIXES is similar to PYTHONUSERBASE: it lets you add "prefix directories" to be culled for site packages. It differs from PYTHONUSERBASE in three w

[Python-Dev] Proposed: a new function-based C API for declaring Python types

EXECUTIVE SUMMARY I've written a patch against py3k trunk creating a new function-based API for creating extension types in C. This allows PyTypeObject to become a (mostly) private structure. THE PROBLEM Here's how you create an extension type using the current API. * First, find some cod

[Python-Dev] Proposed: add support for UNC paths to all functions in ntpath

I've written a patch for Python 3.1 that changes os.path so it handles UNC paths on Windows: http://bugs.python.org/issue5799 In a Windows path string, a UNC path functions *exactly* like a drive letter. This patch means that the Python path split/join functions treats them as if they were

Re: [Python-Dev] Proposed: add support for UNC paths to all functions in ntpath

Counting the votes for http://bugs.python.org/issue5799 : +1 from Mark Hammond (via private mail) +1 from Paul Moore (via the tracker) +1 from Tim Golden (in Python-ideas, though what he literally said was "I'm up for it") +1 from Michael Foord +1 from Eric Smith There have b

[Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

I should have brought this up to python-dev before--sorry for being so slow. It's already in the tracker for a couple of days: http://bugs.python.org/issue5880 The idea: PyGetSetDef has this "void *closure" field that acts like a context pointer. You stick it in the PyGetSetDef, and it

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Mark Dickinson wrote: Still, binary compatibility seems like a fairly strong reason not to remove the closure field. My understanding is that there a) 2.x extension modules are not binary compatible with 3.x, and b) there are essentially no 3.x extension modules in the field. Is that accura

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Amaury Forgeot d'Arc wrote: Larry Hastings wrote: My understanding is that there a) 2.x extension modules are not binary compatible with 3.x, and b) there are essentially no 3.x extension modules in the field. Is that accurate? If we don't have an installed base (yet) to worry ab

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Mark Dickinson wrote: I *think* that third party code that's recompiled for 3.1 and that doesn't use the closure field will either just work, or will produce an easily-fixed compile error. Larry, does this sound right? Yep. But I guess the bigger issue is that extensions already compiled

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Mark Dickinson wrote: This doesn't sound right. The functions in the third party code will get compiled with the wrong signature, so they can crash (or behave unexpectedly) when called by Python. Yes, of course the signature of the getters and setters changes. Please ignore me. :-) If t

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

Casey Duncan wrote: I think this is an important feature, which allows you to define generic, reusable getter and setter functions and pass static metadata to them at runtime. Admittedly I have never needed the full pointer, my typical usage is to pass in an offset. I think this should only

Re: [Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

David Lyon wrote: On Mon, 28 Dec 2009 23:07:32 +, Michael Foord wrote: > Requires-Python: 2.5:2.7 Specifies a range of python versions. So this would work for Python 2.7 but *not* 2.7.1? Or does 2.7 implicitly mean a range of all Python 2.7 versions? Yes. 2.7 would

Re: [Python-Dev] Reworking the GIL

Antoine Pitrou wrote: Also, the MSDN doc (*) says timeBeginPeriod() can have a detrimental effect on system performance; I don't know how much of it is true. (*) http://msdn.microsoft.com/en-us/library/dd757624(VS.85).aspx Indeed it does. This is ancient, dusty wisdom, from the days of 50mhz

Re: [Python-Dev] PEP 3147: PYC Repository Directories

On Sun, Jan 31, 2010 at 1:03 PM, Simon Cross wrote: I don't know whether I in favour of using a single pyr folder or not but if a single folder is used I'd definitely prefer the folder to be called __pyr__ rather than .pyr. Guido van Rossum wrote: Exactly what I would prefer. I worry that ha

Re: [Python-Dev] Proposal for virtualenv functionality in Python

Ian Bicking wrote: This is a proto-proposal for including some functionality from virtualenv in Python itself. I'm not entirely confident about what I'm proposing, so it's not really PEP-ready, but I wanted to get feedback... First, a bit about how virtualenv works (this will use Linux co

Re: [Python-Dev] Proposal for virtualenv functionality in Python

Ian Bicking wrote: On Sun, Feb 21, 2010 at 12:32 PM, Larry Hastings <mailto:la...@hastings.org>> wrote: * Override sys.prefix: allow you to put the binary in someplace other than, say, ~/env/bin/python and still support an environment in ~/env/. Also the use case of looking for lib

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl

M.-A. Lemburg wrote: Backporting PyCapsule is fine, but the changes you made to all those PyCObject uses does not look backwards compatible. The C APIs exposed by the modules (e.g. the datetime module) are used in lots of 3rd party extension modules and changing them from PyCObject to PyCapsule

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl

M.-A. Lemburg wrote: [Y]ou're pretty much breaking all 3rd party modules that have just started using e.g the datetime module C API. Not if they're using PyDateTime_IMPORT. My understanding is that requiring a recompile is okay, and if you use PyDateTime_IMPORT and recompile against 2.7 it

Re: [Python-Dev] [Python-checkins] PyCapsule backport

Just a reply to one part of your message, as I really need to get back to work for now. Antoine Pitrou wrote: I think solution #1 would be the best one. #2 looks too complicated. #2 is a seven-line diff, below. /larry/ Index: cobject.c =

Re: [Python-Dev] [Python-checkins] r79397 - in python/trunk: Doc/c-api/capsule.rst Doc/c-api/cobject.rst Doc/c-api/concrete.rst Doc/data/refcounts.dat Doc/extending/extending.rst Include/Python.h Incl

Well, it's been a couple of days, and nobody has stepped forward to speak in favor of my aggressive PyCapsule schedule. So I will bow to the wishes of those who have spoken up, and scale it back. Specifically, I propose writing a patch that will: * allow the CObject API to (unsafely) d

Re: [Python-Dev] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Distutils] At least one package management tool for 2.7)

anatoly techtonik wrote: So, there won't be any package management tool shipped with Python 2.7 and users will have to download and install `setuptools` manually as before: "search" -> "download" -> "unzip" -> "cmd" -> "cd" -> "python setup.py install" Therefore I still propose shipping boot

Re: [Python-Dev] "-Wd" switch

Jesus Cea wrote: Recently we added "-Wd" flags to buildbots. I was wondering about the effect of it. documentation doesn't help. I could study the code, but I guess other people can have the very same question and I think the answer should be in the archives, somewhere. I studied the code ;)

Re: [Python-Dev] [RELEASE] Python 2.7 released

On 07/04/2010 08:34 AM, Benjamin Peterson wrote: On behalf of the Python development team, I'm jocund to announce the second release candidate of Python 2.7. s/second release candidate/release/ *standing ovation* //larry// ___ Python-Dev mailin

Re: [Python-Dev] Pronouncement needed in issue9675

Hi--sorry to be a little late to the discussion. I'm the putz who backported capsules (and monkeyed with CObject) for 2.7. On 09/27/2010 07:44 PM, Jesus Cea wrote: http://bugs.python.org/issue9675 Long history sort: Python 2.7 backported Capsule support and (incorrectly, in my opinion) ma

Re: [Python-Dev] API for binary operations on Sets

On 09/29/2010 08:50 PM, Raymond Hettinger wrote: 1. Liberalize setobject.c binary operator methods to accept anything registered to the Set ABC and add a backwards incompatible restriction to the Set ABC binary operator methods to only accept Set ABC instances (they currently accept any iterab

[Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

I've never liked the "".join([]) idiom for string concatenation; in my opinion it violates the principles "Beautiful is better than ugly." and "There should be one-- and preferably only one --obvious way to do it.". (And perhaps several others.) To that end I've submitted patch #1569040 to S

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

Gregory P. Smith wrote: > have you run any generic benchmarks such as pystone to get a better > idea of what the net effect on "typical" python code is? I hadn't, but I'm happy to. On my machine (a fire-breathing Athlon 64 x2 4400+), best of three runs: Python 2.5 release: Pystone(1.1) time

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

Fredrik Lundh wrote: > [EMAIL PROTECTED] wrote: > >> MAL's pybench would probably be better for this presuming it does some >> addition with string operands. >> > or stringbench. > I ran 'em, and they are strangely consistent with pystone. With concat, stringbench is ever-so-slightly f

Re: [Python-Dev] PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

I've uploaded a new patch to Sourceforge in response to feedback: * I purged all // comments and fixed all > 80 characters added by my patch, as per Neil Norwitz. * I added a definition of max() for those who don't already have one, as per [EMAIL PROTECTED] It now compiles cleanly on Linux

Re: [Python-Dev] PATCH submitted: Speed up + for string Re: PATCHsubmitted: Speed up + for string concatenation, now as fast as "".join(x) idiom

Chetan Pandya wrote: > The deallocation code needs to be robust for a complex tree - it is > currently not recursive, but needs to be, like the concatenation code. It is already both those things. Deallocation is definitely recursive. See Objects/stringobject.c, function (*ahem*) recursive_deal

Re: [Python-Dev] Python-Dev Digest, Vol 39, Issue 54

Chetan Pandya wrote: I don't have a patch build, since I didn't download the revision used by the patch.  However, I did look at values in the debugger and it looked like x in your example above had a reference count of 2 or more within string_concat even when there were no other assignme

Re: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?

Fredrik Lundh wrote: a dynamic registration approach would be even better, with a single entry point used to register all methods and hooks your C extension has implemented, and code on the other side that builds a properly initialized type descriptor from that set, using fallback functions

[Python-Dev] The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom]

I've significantly enhanced my string-concatenation patch, to the point where that name is no longer accurate.  So I've redubbed it the "lazy strings" patch. The major new feature is that string *slices* are also represented with a lazy-evaluation placeholder for the actual string, just as co

Re: [Python-Dev] The "lazy strings" patch

Martin v. Löwis wrote: > It's not clear to me what you want to achieve with these patches, > in particular, whether you want to see them integrated into Python or > not. > I would be thrilled if they were, but it seems less likely with every passing day. If you have some advice on how I might

Re: [Python-Dev] The "lazy strings" patch

Steve Holden wrote: But it seems to me that the only major issue is the inability to provide zero-byte terminators with this new representation. I guess I wasn't clear in my description of the patch; sorry about that. Like "lazy concatenation objects", "lazy slices" render when you ca

Re: [Python-Dev] The "lazy strings" patch [was: PATCH submitted: Speed up + for string concatenation, now as fast as "".join(x) idiom]

On 2006/10/20, Larry Hastings wrote: > I'm ready to post the patch. Sheesh! Where does the time go. I've finally found the time to re-validate and post the patch. It's SF.net patch #1590352: http://sourceforge.net/tracker/index.php?func=detail&aid=1590352&grou

Re: [Python-Dev] Pydoc Improvements / Rewrite

Ron Adam wrote: Improving pydoc has been suggested before by me and others. I've been working on a version that is probably 80% done and would like to get feed back at this point to determine if I'm approaching this in the best way. Just asking--are you going in a PEP-287-ly way as you work? If

Re: [Python-Dev] Pydoc Improvements / Rewrite

Ron Adam wrote: Thanks for the link. PEP 287 looks to be fairly general in that it expresses a general desire rather than a specification. I thought it was pretty specific. I'd summarize PEP 287 by quoting entry #1 from its "goals of this PEP" section: * To establish reStructuredText as a

[Python-Dev] Deletion order when leaving a scope?

I just ran a quickie experiment and determined: when leaving a scope, variables are deleted FIFO, aka in the same order they were created. This surprised me; I'd expected them to be deleted LIFO, aka last first. Why is it thus? Is this behavior an important feature or an irrelevant side-e

Re: [Python-Dev] [Python-3000] Unipath package

I dropped the Cc: of Python-3000, because I don't think this discussion falls under that mailing list's charter. As I understand it, the Python-3000 mailing list is for discussing the details of implementing Python 3000. "Stuff I'd like to see in Python 3000" doesn't go there, it goes to "P

Re: [Python-Dev] New syntax for 'dynamic' attribute access

Ben North wrote: > Jack Jansen: > >> To me self.[method_name] = self.metadata.[method_name] looks better: >> what we're doing here is more like dictionary lookup than calling >> functions. >> > In the same way, though, would this be viewed as too similar to normal > dictionary/list indexing

Re: [Python-Dev] New syntax for 'dynamic' attribute access

Nick Coghlan wrote: I've tried this out on Brett's urllib & urllib2 examples below. (calling the new builtin attrview() to emphasise the fact that it retains a reference to the original instance). Ooh, ooh! I wanna change my vote! +1 on attrview(), +0.25 on ".[]". Maybe I haven't written en

Re: [Python-Dev] Summary of "dynamic attribute access" discussion

Josiah Carlson wrote: > In a recent source checkout of the trunk Lib, there are 100+ uses of setattr, > 400+ uses of getattr (perhaps 10-20% of which being the 3 argument form), and > a trivial number of delattr calls. I just duplicated this test on all the .py files in the Lib directory tree of

Re: [Python-Dev] Summary of "dynamic attribute access" discussion

Larry Hastings wrote: > I just duplicated this test on all the .py files in the Lib directory > tree of a freshly updated 2.5 trunk. Whoops! Sorry, bungled it again. I counted definitions of __*attr__ too. This time I used "fgrep -w getattr | fgrep 'getattr('" to cul

Re: [Python-Dev] Interning string subtype instances

Greg Ewing wrote: > Can anyone shed any light on this? It seems to me that > by not using this information, only half the benefit of > interning is being achieved. If I understand your question correctly, you're saying "why doesn't string comparison take advantage of interned strings?" If so, the

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

Bob Ippolito wrote: > There is no single PerfectReactor. There are several use cases where > you need to wait on >1 different event systems, which guarantees at > least two OS threads (and two event loops). In general it's nice to > have a single Python event loop ("the reactor") to act on said thr

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

Martin v. Löwis wrote: > Now, for these generalized event loops, it may not be possible anymore > to combine all event sources into a single blocking call. Right, that's why my proposal assumed that each disparate event source would need its own thread. > Ah, threads :-( It turns out that you

Re: [Python-Dev] Twisted Isn't Specific (was Re: Trial balloon: microthreads library in stdlib)

> As others have reported: if you have a gtk reactor and a wx reactor to > support, in addition to a "regular" Win32 reactor (e.g. PythonWin), > your approach still won't work. They all do GetMessage behind the > scenes (sp?), yet you would run them in multiple threads, so they get > their own

Re: [Python-Dev] Py2.6 ideas

Michele Simionato wrote: > ``Contract = namedtuple('Contract stock strike volatility expiration rate > iscall'.split())`` is not that bad either, but I agree that this is a > second order issue. > That also nicely makes another point: this form accepts not just a list of strings but any iterab

[Python-Dev] A "record" type (was Re: Py2.6 ideas)

Larry Hastings wrote: I'd prefer a lightweight frozen dict, let's call it a "record" after one of the suggestions in this thread. That achieves symmetry: mutable & immutable &

Re: [Python-Dev] A "record" type (was Re: Py2.6 ideas)

Steven Bethard wrote: > On 2/20/07, Larry Hastings <[EMAIL PROTECTED]> wrote: >> I considered using __slots__, but that was gonna take too long. > Here's a simple implementation using __slots__: Thanks for steering me to it. However, your implementation and Mr. Hettinge

Re: [Python-Dev] Py2.6 ideas

Josiah Carlson wrote: > Larry Hastings <[EMAIL PROTECTED]> wrote: > >> For new code, I can't think of a single place I'd want to use a >> "NamedTuple" where a "record" wouldn't be arguably more suitable. The >> "NamedT

Re: [Python-Dev] A "record" type (was Re: Py2.6 ideas)

Josiah Carlson wrote: > one thing to note with your method - you can't guarantee the order of the > attributes as they are being displayed. > Actually, my record type *can*; see the hack using the __names__ field. It won't preserve that order during iteration--but it's only a prototype so fa

Re: [Python-Dev] bool conversion wart?

Neal Becker wrote: Instead, bool fails in _the worst possible way_: it silently gives a _wrong result_. I disagree with the word "fail" there; Python is working correctly. The behavior of converting expressions to a boolean is well-defined: http://docs.python.org/ref/Booleans.html Perhaps

Re: [Python-Dev] A "record" type (was Re: Py2.6 ideas)

Josiah Carlson wrote: > Larry Hastings <[EMAIL PROTECTED]> wrote: > >> Josiah Carlson wrote: >> >>> one thing to note with your method - you can't guarantee the order >>> of the attributes as they are being displayed. >>> &

Re: [Python-Dev] splitext('.cshrc')

Martin v. Löwis wrote: Ok - now I'm confused: do you consider this behavior (splitext('.pythonrc') == ('', '.pythonrc')) correct or not? +1 on the behavior. However, the patch is special-casing a leading dot; it would still fail on splitext(".."). If we're gonna fix the bug, I'd rather

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On 03/09/2011 01:15 AM, Stefan Behnel wrote: I can confirm that the Cython project was as surprised of the PyCapsule change in Python 3.2 as (I guess) most other users, I was a bit surprised by it too, and I wrote the Capsule object. (Well, hacked up CObject to give it a new API.) PyCObjec

Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective

On 03/17/2011 07:23 PM, Terry Reedy wrote: As I understand it, the Pyxxx to PyCapsule CAPI warning was put in 2.7. In 2.7, the CObject constructor PyCObject_FromVoidPtr() threw a PendingDeprecationWarning exception. Like other warnings, these aren't active by default. This still caused two

Re: [Python-Dev] API deprecations in Python 3, from a Python 2 perspective

On 03/18/2011 11:20 AM, Jesus Cea wrote: I kind of remember doing this change myself. Since no 2.8 is planned, it seemed sensible to mark PyCObject as a py3k warning. It's all fine by me, and yeah I think you did the change. I'm sure it wasn't me. PS: I am the maintainer of (externally de

[Python-Dev] Call For Topics for Python Language Summit at EuroPython 2011

Howdy howdy. Michael Foord can't make it to EuroPython this year--and congratulations to him on his new baby!--so he's asked me to chair the Python Language Summit in his stead. Although I have some suggested topics from Michael, I don't have any burning issues of my own to add to the dock

Re: [Python-Dev] Problems with the new super()

Barry Warsaw wrote: I think of all the alternatives in PEP 3135, I'd probably prefer self.__super__.foo(), except that I'd call it self.super.foo(). I'm not sure that's sufficient. You need to be able to specify a class when using MI. I'd prefer self.super().foo(). self.super() would take

Re: [Python-Dev] RFC: Add a new builtin strarray type to Python?

On 10/01/2011 09:06 PM, Victor Stinner wrote: Another alternative is a "string-join" object. It is discussed (and implemented) in the following issue, and PyPy has also an optional implementation: http://bugs.python.org/issue1569040 http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizati

Re: [Python-Dev] order of Misc/ACKS

On 11/11/2011 11:03 PM, Stephen J. Turnbull wrote: The sensible thing is to just sort in Unicode code point order, I think. I was going to suggest the official Unicode Collation Algorithm: http://unicode.org/reports/tr10/ But I peeked in the can, saw it was chock-a-block with worms, and d

[Python-Dev] Python 3.4 Release Manager

I've volunteered to be the Release Manager for Python 3.4. The FLUFL has already given it his Sloppy Wet Kiss Of Approval, and we talked to Georg and he was for it too. There's no formal process for selecting the RM, so I may already be stuck with the job, but I thought it best to pipe up

Re: [Python-Dev] PEP 7 clarification request: braces

On 01/02/2012 12:47 AM, Raymond Hettinger wrote: Really? Do we need to have a brace war? People have different preferences. The standard library includes some of both styles depending on what the maintainer thought was cleanest to their eyes in a given context. I'm with Raymond. Code should

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

On 02/15/2012 09:43 AM, Guido van Rossum wrote: *Apart* from the specific use case of making an exact copy of a directory tree that can be verified by other tools that simply compare the nanosecond times for equality, A data point on this specific use case. The following code throws its asse

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

On 02/15/2012 08:12 PM, Guido van Rossum wrote: On Wed, Feb 15, 2012 at 7:28 PM, Larry Hastings wrote: I fixed this in trunk last September (issue 12904); os.utime now preserves all the precision that Python currently conveys. So, essentially you fixed this particular issue without having to

Re: [Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review

On 02/16/2012 02:14 AM, "Martin v. Löwis" wrote: Am 16.02.2012 10:51, schrieb Victor Stinner: 2012/2/16 "Martin v. Löwis": Maybe an alternative PEP could be written that supports the filesystem copying use case only, using some specialized ns APIs? I really think that all you need is st_{a,c,m}

[Python-Dev] Proposing an alternative to PEP 410

I've been meditating on the whole os.stat mtime representation thing. Here's a possible alternative approach. * Improve datetime.datetime objects so they support nanosecond resolution, in such a way that it's 100% painless to make them even more precise in the future. * Add support to date

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

On 02/23/2012 02:35 PM, Victor Stinner wrote: I rejected datetime.datetime because I want to get nanosecond resolution for time and os modules, not only for the os module. If we choose to only patch the os module (*stat() and *utime*() functions), datetime.datetime would be meaningful (e.g. it's

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

On 02/25/2012 03:31 PM, Guido van Rossum wrote: On Sat, Feb 25, 2012 at 1:31 PM, Barry Warsaw wrote: On Feb 23, 2012, at 01:28 PM, Larry Hastings wrote: * Change the result of os.stat to be a custom class rather than a PyStructSequence. Support the sequence protocol on the custom class

Re: [Python-Dev] Rejecting PEP 410 (Use decimal.Decimal type for timestamps)

On 02/25/2012 07:04 PM, Guido van Rossum wrote: As to the changes alluded to in #5: Let os.stat() and friends return extra fields st_atime_ns [...] We don't need a PEP for this proposal; we can just open a tracker issue and hash out the details during the code review. http://bugs.python.org/is

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

On 02/26/2012 06:51 AM, Simon Cross wrote: There are good scientific use cases for nanosecond time resolution (e.g. radio astronomy) where one is actually measuring time down to that level and taking into account propagation delays. I have first hand experience [...] I'm not sure whether any of

Re: [Python-Dev] cpython (3.2): Issue #14123: Explicitly mention that old style % string formatting has caveats

On 02/26/2012 03:33 PM, Guido van Rossum wrote: One thing I'd like to see happening regardless is support for new-style formatting in the logging module. It's a little tricky to think how that would work, alas -- should this be a property of the logger or of the call? There already is some supp

<    3   4   5   6   7   8   9   >