Re: [Python-Dev] With context, please
Phillip J. Eby wrote: > Read the first sentence again: > > "EXPRESSION returns a value that the with statement uses to *create* a > context" (emphasis added). > > It doesn't say that the value *is* the context, and if anything, the > second excerpt supports that by implying that the context manager is the > thing passed to the "with" statement. Things become confused because "context" gets used two different ways: to refer to the context object itself, and the runtime state that the context manager creates. Every case I've seen it used in user-oriented documentation it has referred to the latter. There may be only 2 concrete objects involved, but there's actually three entities of interest - the context object, the context manager, and the nebulous runtime state that makes up the actual "execution context" (i.e. the things the context manager *does* based on the current state of the context object). > Also, there haven't been any complaints of the a1 documentation being > unclear on this; rather, it was the *PEP* that was considered > confusing. So in effect, we already tested this in a1, with one > interpretation in the docs and another in the PEP, and the documenation > won. Except that it breaks down when you actually try to line it up with the code (which is where Paul got stuck when reviewing the documentation yesterday): - decimal.Context: - is not a context according to the current docs - decimal.Context.__context__() returns a decimal.ContextManager object - contextlib.contextmanager() - is actually used to define contexts according to the current docs - but returns a GeneratorContextManager object - contextlib.nested() - uses "contexts" as the name for its arguments - uses "context" as the iteration variable - uses "mgr" as the name for the result of context.__context__() - Compilation/evaluation chain - First clause in With statement is named "context_expr" - parser takes its cue from the AST definition - AST compiler refers to context.__exit__/__enter__ in a comment - ceval refers to context.__exit__ in a comment So the problem is not that the documentation disagrees with the PEP, it's that it disagrees with the *implementation*. contextlib.py, decimal.py, Python.asdl and ast.c consistently use "context" to refer to the original objects provided to the with statement and "context manager" to refer to the return value of the __context__ method. compile.c is confused either way, since it uses "context" for both objects, and ceval.c appears to be taking its cue from compile.c :) (threading.py and fileobject.c just provide the methods directly, so they don't mention the terminology at all) What I'm trying for alpha 2 is to bring the documentation in line with the implementation, because I think that's the root of all of the current confusion. If things still break down, then we can look at changing both the documentation and the implementation to use the alpha 1 terminology post-alpha 2. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)
Terry Reedy a écrit : > So I propose that the context maker be called just that: 'context maker'. > That should pretty clearly not be the context that manages the block > execution. > +1 for context maker. In fact, after reading the begining of the thread, I came up with the very same idea. > Similar, a context_maker function could be named any of 'context_maker', > 'context_manager', or 'context', with the latter two referring to the > return value. In the context of 'with as name:', either of the latter > two reads better to me. > > I would call the decorator @contextmaker since that is what it turns the > decorated function into. > I'm confused here. Do we agree that the object with __enter__ and __exit__ is a context manager, and the object with just __context__ is a context maker ? If so , I would say the decorator still produces a context manager. Baptiste ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch #1454481 - runtime tunable thread stack size
Terry Reedy wrote: > If you checked it in (after tests pass on your ?mac?, and while being ready > to revert), wouldn't the next buildbot cycle do the testing you need? > Isn't testing on 'other' platforms what buildbot is for? Only up to a point... In this case, I was after code review as much as the testing. Regards, Andrew. - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)
Baptiste Carvello wrote: > Terry Reedy a écrit : > > So I propose that the context maker be called just that: 'context > > maker'. That should pretty clearly not be the context that manages > > the block execution. > > > +1 for context maker. In fact, after reading the begining of the > thread, I came up with the very same idea. Or maybe "context factory"? Just ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
On 4/23/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote: > >On Sunday 23 April 2006 11:43, Nick Coghlan wrote: > > > Maybe we need something that's the equivalent of alien (rpm -> dpkg > > > converter), so that given an egg, one can easily get a native > > > installer for that egg. > > > >An 'eggconvert' that used the existing bdist_foo machinery to build > >system specific packages would probably be an ok summer of code > >project, no? > > That's probably not going to be the best way to get from an egg to a system > package, since a lot of the bdist_foo commands try to build things from > source, and an egg for the specific platform is already going to be built, > and won't include source (except for Python modules). Yes. And on Windows at least, building from source can be problematic. Given a binary egg with all the bits included, it's *far* better to just move them around and build an installer from the pieces. It might be possible to unpack the egg into the structure of a distutils "build" directory, and then use bdist_xxx to build the installer on that (on the basis that the build steps will be ignored as the objects are already there - you may have to fiddle a bit to fool distutils into *not* needing source present to check timestamps against...) > Probably you'd want to create something more like Vincenzo Di Massa's > "easy_deb" program, which uses easy_install to find and fetch a source > distribution, then builds a .deb from it. You can currently use: That's certainly not what I want, in two ways: 1. Finding and fetching things isn't needed - I'm happy starting with an egg file on the local filesystem 2. Building from source is not always possible, as I explained above. > So, for any bdist_foo command that's already implemented in the distutils, > you can already get pretty close to this functionality by using a short > shell script that just calls easy_install followed by the setup.py. ... assuming that setup.py build works for you. That's not the use case I am thinking of (which is a 3rd party grabbing a binary egg they couldn't build for themselves, and converting it to the local packaging system). > What you won't get without writing some more code is dependency > support. While I accept that dependency support is very valuable to a lot of people, some of us (the control freaks, maybe :-)) prefer to install dependencies by hand, based on documented requirements. (There's a separate rant here, about the possibility that people stop documenting requirements "because setup.py has them, and they get handled by easy_install", but I'll save that for another day...) But if you're thinking of converting egg dependency data to, for example, deb dependency metadata, then yes, that's an issue. For Windows installers the conversion is easy, of course - just delete the metadata :-) Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] With context, please
On 4/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > - contextlib.contextmanager() > - is actually used to define contexts according to the current docs > - but returns a GeneratorContextManager object You may just be trying to avoid overcomplicating things by adding too much detail here, but you have missed my point about contextmanager - it's used in two, distinct, ways: 1. On a simple function, to define a context manager (that's fine, and in line with the docs) 2. On a __context__ method to define a "function that returns a context" The sticking point is (2), which is *neither a context, nor a context manager*. Purely by coincidence, a context manager will do here, but it's more than is needed. So I still believe that you need 2 separate decorators here (no matter how much implementation they share). I've not looked at your other examples, as I'm deliberately trying *not* to understand the details any further until I've read your proposed docs... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 update (with statement context terminology)
Paul Moore wrote: > On 4/23/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> For those not following along at home, I've now updated PEP 343 to clarify my >> originally intended meanings for various terms, and to record the fact that >> we >> don't currently have a consensus on python-dev that those are the right >> definitions. > > Is it OK if I *don't* read the PEP? I'd rather read the 2.5a2 docs > with a fresh mind, not with preconceived ideas based on the PEP. It > means the feedback gets delayed a bit, but I assume that's OK as > you're planning on including the change in the release anyway. That's fine - the PEP changes are mainly targeted at clearing things up that were ambiguous in the original PEP. Because they were ambiguous, the 2.5a1 implementation went with interpretation A, the documentation went with interpretation B, and so naturally everything fell apart in a confusing heap when the implementation and documentation met in the middle. I'm shifting everything to use the same interpretation as the implementation for alpha 2 (although AMK will have to decide what he wants to do with the what's new section, since that currently mixes and matches the two different interpretations). If people still find it confusing when PEP+implementation+documentation are all using the terminology the same way, then we can look at other possibilities (such as adding a completely new term like 'context definition' for the context objects). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
On Saturday 22 April 2006 15:27, Neal Norwitz wrote: > In case it wasn't clear, the /Wp64 flag is available in icc > (Intel's C compiler). Is it worth turning this on for the icc ubuntu buildbot? Anyone got ideas on the best way to do this? Should I just set CFLAGS="-Wp64" before running the buildbot on the box (it's sitting 2 feet behind my head in the rack in my study(*)) Anthony (*) Yes, I have an almost-rack of machines in my house. And yes, this scares me. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Win64 AMD64 (aka x64) binaries available64
Anthony Baxter wrote: > On Saturday 22 April 2006 15:27, Neal Norwitz wrote: >> In case it wasn't clear, the /Wp64 flag is available in icc >> (Intel's C compiler). > > Is it worth turning this on for the icc ubuntu buildbot? Anyone got > ideas on the best way to do this? Should I just set CFLAGS="-Wp64" > before running the buildbot on the box (it's sitting 2 feet behind my > head in the rack in my study(*)) > > Anthony > > (*) Yes, I have an almost-rack of machines in my house. And yes, this > scares me. You should be scared what people are doing with your machines :-) From http://www.python.org/dev/buildbot/trunk/x86%20Ubuntu%20dapper%20%28icc%29%20trunk/builds/229/step-compile/0 'OPT': '-Wp64 -g -O3' icc -pthread -c -fno-strict-aliasing -Wp64 -g -O3 -I. -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
Tim Peters wrote: >> I've never reported this as a Python bug > > If you do, I'll probably add a comment like the above ;-) > >> because I've considered the antivirus SW likely to be the culprit. > > Could be. FWIW, Norton AV was running during the above. I see a similar phenomenon (sp?) on XP SP2: test_mailbox fails to me, with permission denied in some (random) test. I believe this is due to Tortoise SVN: test_mailbox creates a few directories, then Tortoise detects them (thanks to file change notifications) and tries to walk them, to find out whether that directory is under subversion control. Before Tortoise is done, test_mailbox tries to delete the directories. This (somewhat?) fails - there apparently is a "delete pending" state somehow in the system (sysinternals filemon sometimes shows DELETE PEND as the result of a call). Then, the next test will fail with permission denied. This is a heisenbug: different runs will fail in different tests, and letting sysinternals perform complete tracing make the failure go away. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 update (with statement context terminology)
Nick Coghlan wrote: > For those not following along at home, I've now updated PEP 343 to clarify my > originally intended meanings for various terms, and to record the fact that > we > don't currently have a consensus on python-dev that those are the right > definitions. > > As written up in the PEP, I plan to propagate those interpretations > throughout > the documentation and implementation for 2.5a2, so we have at least one > release using my original vision to see if the terminology actually all hangs > together sensibly the way I believe it does :) Aside from the What's New document, this has now been done. My modifications consisted of terminology changes in the contextlib docs and the language reference to match the 2.5a1 implementation, a Context Types addition to the library reference similar to that for Iterator Types, and a very brief addition to Chapter 8 of the tutorial. It should all filter through the pipeline and appear on python.org in the next few hours. I also looked at the threading and decimal module documentation, but those didn't need any changes - they were correct regardless of which interpretation you applied to the previously ambiguous section in PEP 343. It's up to AMK to decide what he wants to do with What's New for alpha 2. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (wasr45544-peps/trunk/pep-0343.txt)
"Baptiste Carvello" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >+1 for context maker. [me, Terry] >> I would call the decorator @contextmaker since that is what it turns the >> >> decorated function into. >I'm confused here. Do we agree that the object with __enter__ and > >__exit__ is a context manager, I believe so, either that or, for short, context >and the object with just __context__ is a context maker ? If that is what goes after 'with', yes. >If so , I would say the decorator still produces a context manager. If I misunderstood what the decorator produces, then @contextmaker would be wrong. Actually, I thought there were possibly two decorators under consideration, one for each. Terry Jan Reedy Baptiste ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (wasr45544-peps/trunk/pep-0343.txt)
"Just van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >> +1 for context maker. >Or maybe "context factory"? Yes, I thought of that too. Latin 'facere' == 'to make'. I might even put a sentence in the doc explaining that a context maker is a context factory, in the CS sense of the term, just as generator functions are generator factories. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
[Martin] > I see a similar phenomenon (sp?) Yup! The plural is phenomena. > on XP SP2: test_mailbox fails to > me, with permission denied in some (random) test. I believe this > is due to Tortoise SVN: test_mailbox creates a few directories, > then Tortoise detects them (thanks to file change notifications) > and tries to walk them, to find out whether that directory is > under subversion control. > > Before Tortoise is done, test_mailbox tries to delete the directories. > This (somewhat?) fails - there apparently is a "delete pending" state > somehow in the system (sysinternals filemon sometimes shows DELETE PEND > as the result of a call). Then, the next test will fail with permission > denied. > > This is a heisenbug: different runs will fail in different tests, and > letting sysinternals perform complete tracing make the failure go away. I doubt Tortoise is at fault here, just because I never see that kind of failure on my XP Pro SP2 box. Tortoise is _always_ running here, and it's also my buildbot box: there have been over 400 buildbot runs on it, none with "mystery failures" of this kind, and I routinely run -uall release-build tests on it too. It's not that Tortoise is inactive, either. To the contrary, it's a major pig: since I rebooted yesterday, TSVNCache.exe has sucked up > 17 minutes(!) of CPU time, and read up well over a gigabyte from disk. My box isn't magically immune to this kind of problem: I have Copernic Desktop Search installed, and if I enable its "Index new and modified files on the fly" option, then all sorts of things fail in intermittent "permission denied" ways -- from Python tests to CVS updates (unsure about SVN updates -- haven't specifically tried that). IIRC, of the similar reports on c.l.py over the last year that got resolved, all were pinned on background indexing apps (like Copernic) or antivirus software. None of which proves that Tortoise isn't to blame on your box :-) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
Tim Peters wrote:
> [Andrew MacIntyre]
Hmm... I don't appear to have explained what I meant very well :-|
{...}
> This really needs an executable example. Here's my best guess about
> what you mean, but I don't see any of what you're describing on WinXP
> Pro SP2:
And a pretty good guess it was too!
Although I hadn't expected/intended any research to be applied to my note
(except if the original problem involved undeletable files on the
buildbots), I'm relieved your experiment turned up no problem; it makes
the case stronger against something in the local setup.
FWIW, the particular cases I remember seeing involved applications built
with ctypes and Venster (Win32 GUI wrapper over ctypes) with a lot of
COM calls, with Python 2.2.3.
>> I've never reported this as a Python bug
>
> If you do, I'll probably add a comment like the above ;-)
;-)
>> because I've considered the antivirus SW likely to be the culprit.
>
> Could be. FWIW, Norton AV was running during the above.
The anti-virus on my work XP Pro SP2 system has been a source of
considerable annoyance in many situations, so its the first thing
I blame...
>> I don't recall seeing this with Windows 2000, but much was changed
>> in the transition from the Win2k SOE to the WinXP SOE.
>
> What's that? Shitty Out-of-box Experience ;-)?
That too! Our outsourced IT supplier seems to think it means Standard
Operating Environment, but I haven't figured out what's "standard" about
it...
Cheers,
Andrew.
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/ |Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 8 pylintrc?
I had the possibly stupid idea today of running the stdlib through pylint. Has anybody written a pylintrc file that attempts to reflect the recommendations of PEP 8 the extent possible? Thx, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reducing memory overhead for dictionaries by removing me_hash
[Kirat Singh] > Hi, this is my first python dev post, so please forgive me if this topic has > already been discussed. It's hard to find one that hasn't -- but it's even harder to find the old discussions ;-) > It seemed to me that removing me_hash from a dict entry would save 2/3 of > the space 1/3, right? > used by dictionaries and also improve alignment of the entries > since they'd be 8 bytes instead of 12. How would that help? On 32-bit boxes, we have 3 4-byte members in PyDictEntry, and they'll all 4-byte aligned. In what respect related to alignment is that sub-optimal? > And sets end up having just 4 byte entries. > > I'm guessing that string dicts are the most common (hence the specialized > lookupdict_string routine), String dicts were the only kind at first, and their speed is critical because Python itself makes heavy use of them (e.g., to implement instance and module namespaces, and keyword arguments). > and since strings already contain their hash, this would probably mitigate > the performance impact. No slowdown in string dicts would be welcome, but since strings already cache their own hash, they seem unaffected by this. It's the speed of other key types that would suffer, and for classes that define their own __hash__ method that could well be deadly (see Martin's reply for more detail). > One could also add a hash to Tuples since they are immutable. A patch to do that was recently rejected. You can read its comments for some of the reasons: http://www.python.org/sf/1462796 More reasons were given in a python-dev thread about the same thing earlier this month: http://mail.python.org/pipermail/python-dev/2006-April/063275.html > If this isn't a totally stupid idea, I'd be happy to volunteer to try the > experiment and run any suggested tests. I'd be -1 if it slowed dict operations for classes that define their own __hash__. I do a lot of that ;-) > PS any opinion on making _Py_StringEq a macro? Yes: don't bother unless it provably speeds something "important" :-) It's kinda messy for a macro otherwise, macros always make debugging harder (can't step through the source expansion in a debugger w/o a lot of pain), etc. > inline function would be nice but I hesitate to bring up the C/C++ debate, > both > languages suck in their own special way ;-) Does the Python source even compile as C++ now? People have been working toward that, but my last impression was that it's not there yet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiling w/ C++ (was: Reducing memory overhead for dictionaries by removing me_hash)
Tim> Does the Python source even compile as C++ now? People have been Tim> working toward that, but my last impression was that it's not there Tim> yet. Yes, not there yet. I can build the base interpreter, but there are lots of module build problems. I got distracted, but will try to put some more time in on it over the next little while. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reducing memory overhead for dictionaries by removing me_hash
Interesting, thanks for the responses. And yeah I meant 1/3, I always mix up negatives.Agree that as you point out the biggest slowdown will be on classes that define their own __hash__, however since classes use instancedicts and this would reduce the dict size from 96 -> 64 bytes, we could blow 4 bytes to cache the hash on the object. In fact PyObject_Hash could 'intern' the result of __hash__ into a __hashvalue__ member of the class dict. This might be the best of both worlds since it'll only use space for the hashvalue if its needed.Oh and the reason I brought up strings was that one can grab the ob_shash from the stringobject in lookupdict_string to avoid even the function call to get the hash for a string, so its just the same as storing the hash on the entry for strings. The reason I looked into this to begin with was that my code used up a bunch of memory which was traceable to lots of little objects with instance dicts, so it seemed that if instancedicts took less memory I wouldn't have to go and add __slots__ to a bunch of my classes, or rewrite things as tuples/lists, etc. thanks!-KiratOn 4/23/06, Tim Peters <[EMAIL PROTECTED]> wrote: [Kirat Singh]> Hi, this is my first python dev post, so please forgive me if this topic has> already been discussed.It's hard to find one that hasn't -- but it's even harder to find theold discussions ;-) > It seemed to me that removing me_hash from a dict entry would save 2/3 of> the space1/3, right?> used by dictionaries and also improve alignment of the entries> since they'd be 8 bytes instead of 12. How would that help? On 32-bit boxes, we have 3 4-byte members inPyDictEntry, and they'll all 4-byte aligned. In what respect relatedto alignment is that sub-optimal?> And sets end up having just 4 byte entries. >> I'm guessing that string dicts are the most common (hence the specialized> lookupdict_string routine),String dicts were the only kind at first, and their speed is criticalbecause Python itself makes heavy use of them ( e.g., to implementinstance and module namespaces, and keyword arguments).> and since strings already contain their hash, this would probably mitigate> the performance impact.No slowdown in string dicts would be welcome, but since strings already cache their own hash, they seem unaffected by this.It's the speed of other key types that would suffer, and for classesthat define their own __hash__ method that could well be deadly (seeMartin's reply for more detail). > One could also add a hash to Tuples since they are immutable.A patch to do that was recently rejected. You can read its commentsfor some of the reasons: http://www.python.org/sf/1462796More reasons were given in a python-dev thread about the same thingearlier this month: http://mail.python.org/pipermail/python-dev/2006-April/063275.html> If this isn't a totally stupid idea, I'd be happy to volunteer to try the> experiment and run any suggested tests.I'd be -1 if it slowed dict operations for classes that define their own __hash__. I do a lot of that ;-)> PS any opinion on making _Py_StringEq a macro?Yes: don't bother unless it provably speeds something "important" :-) It's kinda messy for a macro otherwise, macros always make debugging harder (can't step through the source expansion in a debugger w/o alot of pain), etc.> inline function would be nice but I hesitate to bring up the C/C++ debate, both> languages suck in their own special way ;-) Does the Python source even compile as C++ now? People have beenworking toward that, but my last impression was that it's not thereyet. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tkinter lockups.
For a while now, I've noticed test_tcl locking up when trying to refleaktest it. I was able to reproduce it quite simply:import Tkinterimport osif "DISPLAY" in os.environ: del os.environ ["DISPLAY"]tcl = Tkinter.Tcl()try: tcl.loadtk()except Exception, e: print etcl.loadtk()Or, more directly, using _tkinter directly:import _tkinter import osif "DISPLAY" in os.environ: del os.environ["DISPLAY"]tk = _tkinter.create(None, "test", "Tk", 0, 1, 0)try: tk.loadtk()except: pass tk.loadtk()In either case, the second loadtk never finishes.It seems that, on my platform at least, Tk_Init() doesn't like being called twice even when the first call resulted in an error. That's Tcl and Tk 8.4.12. Tkapp_Init() (which is the Tkinter part that calls Tk_Init()) does its best to guard against calling Tk_Init() twice when the first call was succesful, but it doesn't remember failure cases. I don't know enough about Tcl/Tk or Tkinter how this is best handled, but it would be mightily convenient if it were. ;-) I've created a bugreport on it, and I hope someone with Tkinter knowledge can step in and fix it. (It looks like SF auto-assigned it to Martin already, hmm.) http://sourceforge.net/tracker/index.php?func=detail&aid=1475162&group_id=5470&atid=105470 -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Reducing memory overhead for dictionaries by removing me_hash
Kirat Singh wrote: > The reason I looked into this to begin with was that my code used up a > bunch of memory which was traceable to lots of little objects with > instance dicts, so it seemed that if instancedicts took less memory I > wouldn't have to go and add __slots__ to a bunch of my classes, or > rewrite things as tuples/lists, etc. Ah. In that case, I would be curious if tuning PyDict_MINSIZE could help. If you have many objects of the same type, am I right assuming they all have the same number of dictionary keys? If so, what is the dictionary size? Do they use ma_smalltable, or do they have an extra ma_table? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 update (with statement context terminology)
> Aside from the What's New document, this has now been done. My modifications > consisted of terminology changes in the contextlib docs and the language > reference to match the 2.5a1 implementation, a Context Types addition to the > library reference similar to that for Iterator Types, and a very brief > addition to Chapter 8 of the tutorial. It should all filter through the > pipeline and appear on python.org in the next few hours. OK, after a *very* quick look, here's my initial impression. I'll do a better look tomorrow. - It seems self-consistent, now, at least. - Surely the __context__ method should be called __contextmgr__ now that it's producing a context manager? (Same naming issue, just the other side of it...) - The addition of the section on context types is useful, no matter what the final naming is. - I don't see why context managers (the ones with __enter__ and __exit__) need a __context__ method as well. To allow both contexts and context managers to be used with the "with" statement, it says. But there's no explanation of why that's a good thing. I see the parallel with "all iterators are iterables", but in the absence of the analog of the iter() builtin, I'm not so sure how I'd ever end up with a raw context manager (short of calling __context__ manually) to use in a with statement. So for my money, the iterator/context analogy breaks down here, precisely because raw iterators are far more common than raw context managers. (Oh, and by the way, writing this sentence reinforced the reason I perfer the old terminology - "context manager" feels like the name of something more concrete than "context", and yet under your new terminology, the "context" is more concrete than the "context manager"!) OK, that's all I'll say for now. As I say, I'll do a better read-through tomorrow. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter lockups.
I just read the manpage for Tk_Init(3) (fc4 package tk-8.4.9-3) and it
does not say that Tk_Init() may only be called once. While this doesn't
mean Python shouldn't work around it, I think the behavior should be
considered a bug in Tk, not _tkinter.
However, on this system, I couldn't recreate the problem you reported
with either the "using _tkinter directly" instructions, or using this
"C" test program:
#include
#include
int main(void) {
Tcl_Interp *trp;
unsetenv("DISPLAY");
trp = Tcl_CreateInterp();
printf("%d\n", Tk_Init(trp));
printf("%d\n", Tk_Init(trp));
return 0;
}
Jeff
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Builtin exit, good in interpreter, bad in code.
A friend of mine is learning Python, and had a problem with the exit
builtin. I like that in the interpreter it gives useful information, but
he was writing a program in a file and tried "exit(0)", and was presented
with the non-obvious error:
TypeError: 'str' object is not callable
What about something like:
>>> class ExitClass:
...def __repr__(self):
... return('Hey, press control-D')
...def __call__(self, value):
... raise SyntaxError, 'You want to use sys.exit'
...
>>> exit = ExitClass()
>>> exit
Hey, press control-D
>>> exit(1)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 5, in __call__
SyntaxError: You want to use sys.exit
Jerub on #python thinks that maybe it needs to subclass the string object
instead, but in general it seems like it might be an improvement.
Thoughts?
Thanks,
Sean
--
Peppermint Patty gets a DSL line in "YOU'D TELL ME IF YOU WERE IN A GERMAN
SCHEISSE VIDEO WOULDN'T YOU, CHARLIE BROWN"
Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]>
tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Builtin exit, good in interpreter, bad in code.
On 4/23/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote:
> A friend of mine is learning Python, and had a problem with the exit
> builtin. I like that in the interpreter it gives useful information, but
> he was writing a program in a file and tried "exit(0)", and was presented
> with the non-obvious error:
>
>TypeError: 'str' object is not callable
>
> What about something like:
>
>>>> class ExitClass:
>...def __repr__(self):
>... return('Hey, press control-D')
>...def __call__(self, value):
>... raise SyntaxError, 'You want to use sys.exit'
>...
>>>> exit = ExitClass()
>>>> exit
>Hey, press control-D
>>>> exit(1)
>Traceback (most recent call last):
> File "", line 1, in ?
> File "", line 5, in __call__
>SyntaxError: You want to use sys.exit
>
> Jerub on #python thinks that maybe it needs to subclass the string object
> instead, but in general it seems like it might be an improvement.
Why don't we just not define 'exit' in non-interactive environments?
--
Crutcher Dunnavant <[EMAIL PROTECTED]>
littlelanguages.com
monket.samedi-studios.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 update (with statement context terminology)
Paul Moore wrote: >> Aside from the What's New document, this has now been done. My modifications >> consisted of terminology changes in the contextlib docs and the language >> reference to match the 2.5a1 implementation, a Context Types addition to the >> library reference similar to that for Iterator Types, and a very brief >> addition to Chapter 8 of the tutorial. It should all filter through the >> pipeline and appear on python.org in the next few hours. > > OK, after a *very* quick look, here's my initial impression. I'll do a > better look tomorrow. > > - It seems self-consistent, now, at least. > > - Surely the __context__ method should be called __contextmgr__ now > that it's producing a context manager? (Same naming issue, just the > other side of it...) The __iter__ method isn't called __iterator__, so why would the __context__ method need to be called "__contextmgr__"? However, I'm definitely starting to agree with Just & Terry and whoever else said it that the basic object needs to be called something other than "context object". "context specifier" or something like that. (in fact, I might make a pass through the PEP & documentation to see how that looks. . .) > - I don't see why context managers (the ones with __enter__ and > __exit__) need a __context__ method as well. To allow both contexts > and context managers to be used with the "with" statement, it says. > But there's no explanation of why that's a good thing. I see the > parallel with "all iterators are iterables", but in the absence of the > analog of the iter() builtin, I'm not so sure how I'd ever end up with > a raw context manager (short of calling __context__ manually) to use > in a with statement. So for my money, the iterator/context analogy > breaks down here, precisely because raw iterators are far more common > than raw context managers. Context objects in the 2.5 standard library: decimal.Context Context managers in the 2.5 standard library: file threading.Lock threading.RLock threading.Condition threading.Semaphore threading.BoundedSemaphore Code that manipulates both context objects and context managers (like contextlib.nested, and the with statement itself) needs to be able to ignore the distinction. And yes, such code does indeed call __context__() directly in order to get hold of the context manager. (Oh, and by the way, writing this sentence > reinforced the reason I perfer the old terminology - "context manager" > feels like the name of something more concrete than "context", and yet > under your new terminology, the "context" is more concrete than the > "context manager"!) This is why I'm starting to think Terry and Just are right - the name of that type needs to be something other than "context object" in order to reduce the current ambiguity. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are contexts also managers? (wasr45544 -peps/trunk/pep-0343.txt)
Just van Rossum wrote: > Baptiste Carvello wrote: > >> Terry Reedy a écrit : >>> So I propose that the context maker be called just that: 'context >>> maker'. That should pretty clearly not be the context that manages >>> the block execution. >>> >> +1 for context maker. In fact, after reading the begining of the >> thread, I came up with the very same idea. > > Or maybe "context factory"? That would be fine if we used __call__ to retrieve the context manager - but "factory" is too tightly bound to "factory function" in my mind. I'm going to try a pass through the docs using "context specifier", which gives three separate terms: - context specifier: An object with a __context__ method that produces a context manager object to manipulate the runtime context - context manager: An object with __enter__ and __exit__ methods that manipulate the runtime context. - context (or runtime context): The actual changes made to the runtime state by the context manager based on the current state of the context specifier This removes the ambiguity between "context object" and "runtime context". Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Proposed addition to threading module - released
Do we want to add a "released" context manager to the threading module for 2.5? It was mentioned using the name "unlocked" in PEP 343, but never spelt out: class released(object): def __init__(self, lock): self.lock = lock def __enter__(self): self.lock.release() def __exit__(self, *exc_info): self.lock.acquire() (This context manager is the equivalent of PEP 319's asynchronize keyword) Usage would be: from threading import RLock, released sync_lock = RLock() def thread_safe(): with sync_lock: # This is thread-safe with released(sync_lock): # Perform long-running or blocking operation # that doesn't need to hold the lock # We have the lock back here (This particular example could be handled by two separate "with sync_lock" statements with the asynchronous operation between them, but other cases put the asynchronous operation inside a loop or a conditional statement which means that particular trick won't work). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] windows buildbot failures
Tim: > [Martin] > > on XP SP2: test_mailbox fails to > > me, with permission denied in some (random) test. I believe this > > is due to Tortoise SVN: test_mailbox creates a few directories, > > then Tortoise detects them (thanks to file change notifications) > > and tries to walk them, to find out whether that directory is > > under subversion control. ... > I doubt Tortoise is at fault here, just because I never see that kind > of failure on my XP Pro SP2 box. Tortoise is _always_ running here, > and it's also my buildbot box: there have been over 400 buildbot runs FWIW, I've seen similar issues caused by the MS 'Index Server'. Disabling the Index Server service made my problem go away. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Builtin exit, good in interpreter, bad in code.
Sean Reifschneider wrote: > Thoughts? In Python 2.5, exit(0) exits. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed addition to threading module - released
Nick Coghlan wrote: > Do we want to add a "released" context manager to the threading module for > 2.5? I don't think that should be added. I would consider it a dangerous programming style: if the lock merely doesn't "need" to be held (i.e. if it isn't necessary, but won't hurt), one should just keep holding the lock. If it is essential to release the lock, because the code would otherwise deadlock, the code should be dramatically revised to avoid that situation, e.g. by redefining the granularity of the lock, and moving the with statements accordingly. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Builtin exit, good in interpreter, bad in code.
Sean Reifschneider wrote: > Thoughts? As Martin pointed out, this was fixed for 2.5a1: C:\>type demo.bat @c:\python%1\python -c "exit()" @echo %ERRORLEVEL% C:\>demo 24 Traceback (most recent call last): File "", line 1, in ? TypeError: 'str' object is not callable 1 C:\>demo 25 0 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
