Re: [Python-Dev] buildbot vs. Windows
On 2/20/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > Speaking as a PSF director, I might not vote for that :-) Fact is > I've been keeping the build & tests 100% healthy on WinXP Pro, and > that requires more than just running the tests (it also requires > repairing compiler warnings and Unixisms). These are some ways we need buildbot to help us more. IMO compiler warnings should generate emails from buildbot. We would need to filter out a bunch, but it would be desirable to know about warnings on different architectures. Unfortunately, there are a ton of warnings on OS X right now. > Adding -r to the buildbot test recipe is a decent idea. Getting > _some_ debug-build test runs would also be good (or do we do that > already?). Buildbot runs "make testall" which does not run the tests in random order. There's nothing to prevent buildbot from making debug builds, though that is not currently done. The builds I run on the x86 box every 12 hours *do* use debug builds (Misc/build.sh). The results are here: http://docs.python.org/dev/results/ I also recently switched the email to go to python-checkins, though there haven't been any failures yet (unless they are sitting in a spam queue). There are some hangs (like right now): Thread 1: Lib/threading.py (204): wait Lib/threading.py (543): join Lib/threading.py (637): __exitfunc Lib/atexit.py (25): _run_exitfuncs Thread 2: Lib/socket.py (170): accept Lib/SocketServer.py (373): get_request Lib/SocketServer.py (218): handle_request Lib/test/test_socketserver.py (33): serve_a_few Lib/test/test_socketserver.py (82): run Lib/threading.py (445): __bootstrap I've seen test_socketserver fail before, this could be due to running 2 tests simultaneously. > Anyway, since XP Pro is effectively covered, I'd be keener to see a > Windows buildbot running under a different flavor of Windows. +1 n ___ 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] Memory Error the right error for coding cookie promise violation?
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote:
> Perhaps a more informative message would be nice.
> Here's an easy way to trigger it:
>
> >>> compile("#-*- coding: ascii -*-\nprint 'ab%c'\n"%0x80, '','exec')
> Traceback (most recent call last):
>File "", line 1, in ?
> MemoryError
This was fixed in 2.5, but looks like it wasn't backported. I don't
recall exactly why. -- n
Python 2.5a0 (trunk:42526M, Feb 20 2006, 16:00:48)
>>> compile("#-*- coding: ascii -*-\nprint 'ab%c'\n"%0x80, '','exec')
Traceback (most recent call last):
File "", line 1, in
File "", line 0
SyntaxError: unknown encoding: ascii
___
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] Removing Non-Unicode Support?
M.-A. Lemburg wrote: > I'd say that the parties interested in non-Unicode versions of > Python should maintain these branches of Python. Dito for other > stripped down versions. I understand where you're coming from but the embedded market I encounter tends to focus on the hardware side. If they can get a marketing star by grabbing Python off-the shelf, tweak the build and produce something to include with their product, they will. But if they have to maintain a branch, they'll just go with the defacto C API most such devices use. > Note that this does not mean that we should forget about memory > consumption issues. It's just that if there's only marginal > interest in certain special builds of Python, I don't see the > requirement for the Python core developers to maintain them. These requirements of customization may not be a strong case for today but could be impacting future growth of the language in certain sectors. I'm a rabid Python evangelist and alway try to push Python into more nooks and crannies of the marketplace, similar to how the Linux kernel is available from the tiniest machines to the largest iron. If the focus of Python is to be strictly a desktop, conventional (mostly ;-) language, restricting its adaptability to other less interesting environments may be a reasonable tradeoff to improve its maintainability. But adaptability, especially when you don't fully grok where or how it will be used, can also be a competitive advantage. -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
Re: [Python-Dev] buildbot vs. Windows
On 21-feb-2006, at 9:09, Neal Norwitz wrote: > Unfortunately, there are a ton of > warnings on OS X right now. How many of those do you see when you ignore the warnings you get while building the Carbon extensions? Those extensions wrap loads of deprecated functions, each of which will give a warning. Ronald ___ 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] buildbot vs. Windows
On 2/21/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > On 21-feb-2006, at 9:09, Neal Norwitz wrote: > > > Unfortunately, there are a ton of > > warnings on OS X right now. > > How many of those do you see when you ignore the warnings you get > while building the Carbon extensions? Those extensions wrap loads of > deprecated functions, each of which will give a warning. RIght: http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/138/step-compile/0 Most but not all of the warnings are due to Carbon AFAICT. I'd like to fix those that are important, but it's so far down on the priority list. :-( n ___ 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] buildbot vs. Windows
On 21-feb-2006, at 10:19, Neal Norwitz wrote: > On 2/21/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote: >> >> On 21-feb-2006, at 9:09, Neal Norwitz wrote: >> >>> Unfortunately, there are a ton of >>> warnings on OS X right now. >> >> How many of those do you see when you ignore the warnings you get >> while building the Carbon extensions? Those extensions wrap loads of >> deprecated functions, each of which will give a warning. > > RIght: > http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/ > 138/step-compile/0 > > Most but not all of the warnings are due to Carbon AFAICT. I'd like > to fix those that are important, but it's so far down on the priority > list. :-( I'm working with Bob I. on a universal binary build of python 2.4. Some of our patches fix warnings like the ones for _CFmodule.c. I'll be starting with submitting the less controversial patches once the universal build is mostly ready, which should be any day now. Ronald > > n ___ 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] Removing Non-Unicode Support?
Martin v. Löwis wrote: > M.-A. Lemburg wrote: >> Note that this does not mean that we should forget about memory >> consumption issues. It's just that if there's only marginal >> interest in certain special builds of Python, I don't see the >> requirement for the Python core developers to maintain them. > > Well, the cost of Unicode support is not so much in the algorithmic > part, but in the tables that come along with it. AFAICT, everything > but unicodectype is optional; that is 5KiB of code and 20KiB of data > on x86. Actually, the size of the code *does* matter, at a second > glance. Here are the largest object files in the Python code base > on my system (not counting dynamic modules): > >textdata bss dec hex filename >4845 19968 0 2481360ed Objects/unicodectype.o > 226332432 352 254176349 Objects/listobject.o > 292591412 152 308237867 Objects/classobject.o > 20696 11488 4 321887dbc Python/bltinmodule.o > 33579 740 0 34319860f Objects/longobject.o > 34119 16 288 344238677 Python/ceval.o > 351792796 0 379759457 Modules/_sre.o > 26539 15820 416 42775a717 Modules/posixmodule.o > 3528388001056 45139b053 Objects/stringobject.o > 50360 0 28 50388c4d4 Python/compile.o > 684554624 440 73519 11f2f Objects/typeobject.o > 6999393161196 80505 13a79 Objects/unicodeobject.o > > So it appears that dropping Unicode support can indeed provide > some savings. > > For reference, we also have an option to drop complex numbers: > >9654 692 4 10350286e Objects/complexobject.o So why not drop that as well ? Note that I'm not saying that these switches are useless - of course they do allow to strip down the Python interpreter. I believe that only very few people are interested in having these options and it's fair enough to put the burden of maintaining these branches on them. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Removing Non-Unicode Support?
Jeff Rush wrote: > M.-A. Lemburg wrote: > >> I'd say that the parties interested in non-Unicode versions of >> Python should maintain these branches of Python. Dito for other >> stripped down versions. > > I understand where you're coming from but the embedded market I > encounter tends to focus on the hardware side. If they can get a > marketing star by grabbing Python off-the shelf, tweak the build and > produce something to include with their product, they will. But if they > have to maintain a branch, they'll just go with the defacto C API most > such devices use. > >> Note that this does not mean that we should forget about memory >> consumption issues. It's just that if there's only marginal >> interest in certain special builds of Python, I don't see the >> requirement for the Python core developers to maintain them. > > These requirements of customization may not be a strong case for today > but could be impacting future growth of the language in certain > sectors. I'm a rabid Python evangelist and alway try to push Python > into more nooks and crannies of the marketplace, similar to how the > Linux kernel is available from the tiniest machines to the largest > iron. If the focus of Python is to be strictly a desktop, conventional > (mostly ;-) language, restricting its adaptability to other less > interesting environments may be a reasonable tradeoff to improve its > maintainability. But adaptability, especially when you don't fully grok > where or how it will be used, can also be a competitive advantage. I don't think this is a strong enough case to warrant having to maintain a separate branch of the Python core. Even platforms like Palm nowadays have enough RAM to cope with the 100kB or so that Unicode support adds. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] defaultdict proposal round three
Delaney, Timothy (Tim) wrote: > However, *because* Python uses duck typing, I tend to feel that > subclasses in Python *should* be drop-in replacements. Duck-typing means that the only reliable way to assess whether two types are sufficiently compatible for some purpose is to consult the documentation -- you can't just look at the base class list. I think this should work both ways. It should be okay to *not* document autodict as being a subclass of dict, even if it happens to be implemented that way. I've adopted a convention like this in PyGUI, where I document the classes in terms of a conceptual interface hierarchy, without promising that they will be implemented that way. Greg ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]
Ron Adam wrote: > Storing byte information as 16 or 32 bits ints could take up a rather > lot of memory in some cases. I don't quite see the point here. Inside a bytes object, they would be stored 1 byte per byte. Nobody is suggesting that they would take up more than that just because a_bytes_object[i] happens to return an int. So the only reason to introduce a new "byte" type is to remove some of the operations that int has. We can already do bitwise operations on an int, so we don't need a new type to add that capability. What's more, I can see this leading to people asking for arithmetic operations to be *added* to the byte type so they can do wrap-around arithmetic, and then for 16-bit, 32-bit, 64-bit etc. versions of it, etc. etc. Do we really want to get onto that slope? Greg ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]
Ron Adam wrote: > Storing byte information as 16 or 32 bits ints could take up a rather > lot of memory in some cases. I don't quite see the point here. Inside a bytes object, they would be stored 1 byte per byte. Nobody is suggesting that they would take up more than that just because a_bytes_object[i] happens to return an int. So the only reason to introduce a new "byte" type is to remove some of the operations that int has. We can already do bitwise operations on an int, so we don't need a new type to add that capability. What's more, I can see this leading to people asking for arithmetic operations to be *added* to the byte type so they can do wrap-around arithmetic, and then for 16-bit, 32-bit, 64-bit etc. versions of it, etc. etc. Do we really want to get onto that slope? Greg ___ 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] defaultdict proposal round three
Guido van Rossum wrote: > It's quite tricky to implement a fully > transparent wrapper that supports all the special > methods (__setitem__ etc.). I was thinking the wrapper would only be a means of filling the dict -- it wouldn't even pretend to implement the full dict interface. The only method it would really need to have is __getitem__. > The semantics of defaultdict are crystal clear. __contains__(), keys() > and friends represent the *actual*, *current* keys. If you're happy with that, then I am too. I was never particularly attached to the wrapper idea -- I just mentioned it as a possible alternative. Just one more thing -- have you made a final decision about the name yet? I'd still prefer something like 'autodict', because to me 'defaultdict' suggests a type that just returns default values without modifying the dict. Maybe it should be reserved for some possible future type that behaves that way. Also, considering the intended use cases (accumulation, etc.) it seems more accurate to think of the value produced by the factory as an 'initial value' rather than a 'default value', and I'd prefer to see it described that way in the docs. If that is done, having 'default' in the name wouldn't be so appropriate. Greg ___ 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] bytes.from_hex()
Stephen J. Turnbull wrote: > What I advocate for Python is to require that the standard base64 > codec be defined only on bytes, and always produce bytes. I don't understand that. It seems quite clear to me that base64 encoding (in the general sense of encoding, not the unicode sense) takes binary data (bytes) and produces characters. That's the whole point of base64 -- so you can send arbitrary data over a channel that is only capable of dealing with characters. So in Py3k the correct usage would be base64unicode encodeencode(x) original bytes > unicode -> bytes for transmission < <- base64unicode decodedecode(x) where x is whatever unicode encoding the transmission channel uses for characters (probably ascii or an ascii superset, but not necessarily). So, however it's spelled, the typing is such that base64_encode(bytes) --> unicode and base64_decode(unicode) --> bytes -- Greg ___ 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] defaultdict proposal round three
Bengt Richter wrote: > you could write > > d = dict()**list Or alternatively, ld = dict[list] i.e. "a dict of lists". In the maximally twisted form of this idea, the result wouldn't be a dict but a new *type* of dict, which you would then instantiate: d = ld(your_favourite_args_here) This solves both the constructor-argument problem (the new type can have the same constructor signature as a regular dict with no conflict) and the perceived-Liskov-nonsubstitutability problem (there's no requirement that the new type have any particular conceptual and/or actual inheritance relationship to any other type). Plus being a really cool introduction to the concepts of metaclasses, higher-order functions and all that neat head-exploding stuff. :-) Resolving-not-to-coin-any-more-multihyphenated- hyperpolysyllabic-words-like-'perceived-Liskov- nonsubstitutability'-this-week-ly, Greg ___ 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] Papal encyclical on the use of closures (Re: PEP for Better Control of Nested Lexical Scopes)
Josiah Carlson wrote: > Introducing these two new keywords is equivalent to > encouraging nested scope use. Right now nested scope > use is "limited" or "fraught with gotchas". What you seem to be saying here is: Nested scope use is Inherently Bad. Therefore we will keep them Limited and Fraught With Gotchas, so people will be discouraged from using them. Sounds a bit like the attitude of certain religious groups to condoms. (Might encourage people to have sex -- can't have that -- look at all the nasty diseases you can get!) Greg ___ 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] defaultdict proposal round three
Greg Ewing wrote: >Delaney, Timothy (Tim) wrote: > > > >>However, *because* Python uses duck typing, I tend to feel that >>subclasses in Python *should* be drop-in replacements. >> >> > >Duck-typing means that the only reliable way to >assess whether two types are sufficiently compatible >for some purpose is to consult the documentation -- >you can't just look at the base class list. > > > What's the API for that ? I've had problems in code that needs to treat strings, lists and dictionaries differently (assigning values to a container where all three need different handling) and telling the difference but allowing duck typing is *problematic*. Slightly-off-topic'ly-yours, Michael Foord ___ 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 for Better Control of Nested Lexical Scopes
Josiah Carlson wrote: > Mechanisms which rely on manipulating variables within closures or > nested scopes to function properly can be elegant, but I've not yet seen > one that *really* is. It seems a bit inconsistent to say on the one hand that direct assignment to a name in an outer scope is not sufficiently useful to be worth supporting, while at the same time providing a way to do it for one particular scope, i.e. 'global'. Would you advocate doing away with it? > Of course using > classes directly with a bit of work can offer you everything you want > from a closure, with all of the explcitness that you could ever want. There are cases where the overhead (in terms of amount of code) of defining a class and creating an instance of it swamps the code which does the actual work, and, I feel, actually obscures what is being done rather than clarifies it. These cases benefit from the ability to refer to names in enclosing scopes, and I believe they would benefit further from the ability to assign to such names. Certainly the feature could be abused, as can the existing nested scope facilities, or any other language feature for that matter. Mere potential for abuse is not sufficient reason to reject a feature, or the language would have no features at all. Another consideration is efficiency. CPython currently implements access to local variables (both in the current scope and all outer ones except the module scope) in an extremely efficient way. There's always the worry that using attribute access in place of local variable access is greatly increasing the runtime overhead for no corresponding benefit. You mention the idea of namespaces. Maybe an answer is to provide some lightweight way of defining a temporary, singe-use namespace for use within nested scopes -- lightweight in terms of both code volume and runtime overhead. Perhaps something like def my_func(): namespace foo foo.x = 42 def inc_x(): foo.x += 1 The idea here is that foo wouldn't be an object in its own right, but just a collection of names that would be implemented as local variables of my_func. Greg ___ 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] buildbot vs. Windows
Neal> IMO compiler warnings should generate emails from buildbot. It doesn't generate emails for any other condition. I think it should just turn the compilation section yellow. 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] buildbot vs. Windows
>> Unfortunately, there are a ton of warnings on OS X right now. Ronald> How many of those do you see when you ignore the warnings you Ronald> get while building the Carbon extensions? I see a bunch related to Py_ssize_t. Those have nothing to do with Carbon. I don't see them on the gentoo build, so I assume they just haven't been tackled yet. 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] bytes type discussion
On Fri, 2006-02-17 at 00:43 -0500, Steve Holden wrote: > Fredrik Lundh wrote: > > Barry Warsaw wrote: > > > > > >>We know at least there will never be a 2.10, so I think we still have > >>time. > > > > > > because there's no way to count to 10 if you only have one digit? > > > > we used to think that back when the gas price was just below 10 SEK/L, > > but they found a way... > > > IIRC Guido is on record as saying "There will be no Python 2.10 because > I hate the ambiguity of double-digit minor release numbers", or words to > that effect. I heard the same quote, so that's what I was referring to! -Barry signature.asc Description: This is a digitally signed message part ___ 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] bytes.from_hex()
On Sun, 2006-02-19 at 23:30 +0900, Stephen J. Turnbull wrote: > > "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > M> * for Unicode codecs the original form is Unicode, the derived > M> form is, in most cases, a string > > First of all, that's Martin's point! > > Second, almost all Americans, a large majority of Japanese, and I > would bet most Western Europeans would say you have that backwards. > That's the problem, and it's the Unicode advocates' problem (ie, > ours), not the users'. Even if we're right: education will require > lots of effort. Rather, we should just make it as easy as possible to > do it right, and hard to do it wrong. I think you've hit the nail squarely on the head. Even though I /know/ what the intended semantics are, the originality of the string form is deeply embedded in my nearly 30 years of programming experience, almost all of it completely American English-centric. I always have to stop and think about which direction .encode() and .decode() go in because it simply doesn't feel natural. Or more simply put, my brain knows what's right, but my heart doesn't and that's why converting from one to the other is always a hiccup in the smooth flow of coding. And while I'm sympathetic to MAL's design decisions, the overlaying of the generalizations doesn't help. -Barry signature.asc Description: This is a digitally signed message part ___ 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 for Better Control of Nested Lexical Scopes
Almann, The lack of support for rebinding names in enclosing scopes is certainly a wart. I think option one is a better fit for Python, because it more closely matches the existing naming semantics. Namely that assignment in a block creates a new name unless a global statement indicates otherwise. The revised rules would be that assignment creates a new name unless a global or XXX statement indicates otherwise. The names of naming statements are quite hard to get right, I fear. I don't particularly like "use." It's too generic. (I don't particularly like "scope" for option 2, either, for similar reasons. It doesn't indicate what kind of scope issue is being declared.) The most specifc thing I can think of is "free" to indicate that the variable is free in the current scope. It may be too specialized a term to be familiar to most people. I think free == global in the absence of other bindings. Jeremy On 2/20/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: > I am considering developing a PEP for enabling a mechanism to assign to free > variables in a closure (nested function). My rationale is that with the > advent of PEP 227 , Python has proper nested lexical scopes, but can have > undesirable behavior (especially with new developers) when a user makes > wants to make an assignment to a free variable within a nested function. > Furthermore, after seeing numerous kludges to "solve" the problem with a > mutable object, like a list, as the free variable do not seem "Pythonic." I > have also seen mention that the use of classes can mitigate this, but that > seems, IMHO, heavy handed in cases when an elegant solution using a closure > would suffice and be more appropriate--especially when Python already has > nested lexical scopes. > > I propose two possible approaches to solve this issue: > > 1. Adding a keyword such as "use" that would follow similar semantics as > "global" does today. A nested scope could declare names with this keyword > to enable assignment to such names to change the closest parent's binding. > The semantic would be to keep the behavior we experience today but tell the > compiler/interpreter that a name declared with the "use" keyword would > explicitly use an enclosing scope. I personally like this approach the most > since it would seem to be in keeping with the current way the language works > and would probably be the most backwards compatible. The semantics for how > this interacts with the global scope would also need to be defined (should > "use" be equivalent to a global when no name exists all parent scopes, etc.) > > > def incgen( inc = 1 ) : >a = 6 >def incrementer() : > use a > #use a, inc <-- list of names okay too > a += inc > return a >return incrementer > > Of course, this approach suffers from a downside that every nested scope > that wanted to assign to a parent scope's name would need to have the "use" > keyword for those names--but one could argue that this is in keeping with > one of Python's philosophies that "Explicit is better than implicit" (PEP > 20). This approach also has to deal with a user declaring a name with " > use" that is a named parameter--this would be a semantic error that could be > handled like "global " does today with a SyntaxError. > > 2. Adding a keyword such as "scope" that would behave similarly to > JavaScript's " var" keyword. A name could be declared with such a keyword > optionally and all nested scopes would use the declaring scope's binding > when accessing or assigning to a particular name. This approach has similar > benefits to my first approach, but is clearly more top-down than the first > approach. Subsequent "scope" declarations would create a new binding at the > declaring scope for the declaring and child scopes to use. This could > potentially be a gotcha for users expecting the binding semantics in place > today. Also the scope keyword would have to be allowed to be used on > parameters to allow such parameter names to be used in a similar fashion in > a child scope. > > > def incgen( inc = 1 ) : >#scope inc <-- allow scope declaration for bound parameters (not a big > fan of this) >scope a = 6 >def incrementer() : > a += inc > return a >return incrementer > > This approach would be similar to languages like JavaScript that allow for > explicit scope binding with the use of "var" or more static languages that > allow re-declaring names at lower scopes. I am less in favor of this, > because I don't think it feels very "Pythonic". > > As a point of reference, some languages such as Ruby will only bind a new > name to a scope on assignment when an enclosing scope does not have the name > bound. I do believe the Python name binding semantics have issues (for > which the "global" keyword was born), but I feel that the "fixing" the > Python semantic to a more "Ruby-like" one adds as many problems as it solves > since the "Ruby-like" one is just
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
Jeremy, I definitely agree that option one is more in line with the semantics in place within Python today. > The names of naming statements are quite hard to get right, I fear. I > don't particularly like "use." It's too generic. (I don't > particularly like "scope" for option 2, either, for similar reasons. > It doesn't indicate what kind of scope issue is being declared.) The > most specifc thing I can think of is "free" to indicate that the > variable is free in the current scope. It may be too specialized a > term to be familiar to most people. I am not married to any particular keyword for sure--I would be happy for the most part if the language was fixed regardless of the keyword chosen. "free" gives me the sense that I am de-allocating memory (my C background talking), I don't think most people would get the mathematical reference for "free". I certainly hope that an initiative like this doesn't get stymied by the lack of a good name for such a keyword. Maybe something like "outer"? > I think free == global in the absence of other bindings. I actually like this, would sort of make "global" obsolete (and thus making the global scope behave like other lexical scopes with regard to to re-binding, which is probably a good thing) -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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] defaultdict proposal round three
On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > How about doing it as an expression, empowering ( ;-) the dict just afer > creation? > E.g., for > > d = dict() > d.default_factory = list > > you could write > > d = dict()**list Bengt, can you let your overactive imagination rest for a while? I recommend that you sit back, relax for a season, and reflect on the zen nature of Pythonicity. Then come back and hopefully you'll be able to post without embarrassing yourself continuously. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] defaultdict proposal round three
On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote: > I've had problems in code that needs to treat strings, lists and > dictionaries differently (assigning values to a container where all > three need different handling) and telling the difference but allowing > duck typing is *problematic*. Consider designing APIs that don't require you to mae that kind of distinction, if you're worried about edge cases and classifying arbitrary other objects correctly. It's totally possible to create an object that behaves like a hybrid of a string and a dict. If you're only interested in classifying the three specific built-ins you mention, I'd check for the presense of certain attributes: hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort") -> x is a list; hasattr(x, "update") -> x is a dict. Also, hasattr(x, "union") -> x is a set; hasattr(x, "readline") -> x is a file. That's duck typing! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] buildbot vs. Windows
Ronald> How many of those do you see when you ignore the warnings you Ronald> get while building the Carbon extensions? skip> I see a bunch related to Py_ssize_t. Those have nothing to do skip> with Carbon. I don't see them on the gentoo build, so I assume skip> they just haven't been tackled yet. Let me rephrase that. I assume the people digging through Py_ssize_t issues have been looking at compilation warnings for platforms other than Mac OSX. 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] PEP for Better Control of Nested Lexical Scopes
On Tue, Feb 21, 2006 at 08:02:08AM -0500, Jeremy Hylton wrote: > The lack of support for rebinding names in enclosing scopes is > certainly a wart. I think option one is a better fit for Python, > because it more closely matches the existing naming semantics. Namely > that assignment in a block creates a new name unless a global > statement indicates otherwise. The revised rules would be that > assignment creates a new name unless a global or XXX statement > indicates otherwise. I agree with Jeremy on this. I've been thinking about doing something like this myself, but never got 'round to it. It doesn't make working with closures much easier, and I doubt it'll encourage using closures much, but it does remove the wart of needing to use mutable objects to make them read-write. > The names of naming statements are quite hard to get right, I fear. I > don't particularly like "use." It's too generic. (I don't > particularly like "scope" for option 2, either, for similar reasons. > It doesn't indicate what kind of scope issue is being declared.) The > most specifc thing I can think of is "free" to indicate that the > variable is free in the current scope. It may be too specialized a > term to be familiar to most people. I was contemplating 'enclosed' as a declaration, myself. Maybe, if there's enough of a consent on any name before Python 2.5a1 is released, and the feature isn't going to make it into 2.5, we could ease the introduction of a new keyword by issuing warning about the keyword in 2.5 already. (Rather than a future-import to enable it in 2.6.) Maybe, and only if there's no doubt about how it's going in, of course. -- 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] PEP for Better Control of Nested Lexical Scopes
On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote: >Almann, > >The lack of support for rebinding names in enclosing scopes is >certainly a wart. I think option one is a better fit for Python, >because it more closely matches the existing naming semantics. Namely >that assignment in a block creates a new name unless a global >statement indicates otherwise. The revised rules would be that >assignment creates a new name unless a global or XXX statement >indicates otherwise. > >The names of naming statements are quite hard to get right, I fear. I >don't particularly like "use." It's too generic. (I don't >particularly like "scope" for option 2, either, for similar reasons. >It doesn't indicate what kind of scope issue is being declared.) The >most specifc thing I can think of is "free" to indicate that the >variable is free in the current scope. It may be too specialized a >term to be familiar to most people. > >I think free == global in the absence of other bindings. > >Jeremy Hey, only Guido is allowed to top-post. He said so ;-) But to the topic, it just occurred to me that any outer scopes could be given names (including global namespace, but that would have the name global by default, so global.x would essentially mean what globals()['x'] means now, except it would be a name error if x didn't pre-exist when accessed via namespace_name.name_in_space notation. namespace g_alias # g_alias.x becomes alternate spelling of global.x def outer(): namespace mezzanine a = 123 print a # => 123 print mezzanine.a # => 123 (the name space name is visible and functional locally) def inner(): print mezzanine.a => 123 mezznine.a =456 inner() print a # = 456 global.x = re-binds global x, name error if not preexisting. This would allow creating mezzanine like an attribute view of the slots in that local namespace, as well as making namespace itself visible there, so the access to mezzanine would look like a read access to an ordinary object named mezzanine that happened to have attribute slots matching outer's local name space. Efficiency might make it desirable not to extend named namespaces with new names, function locals being slotted in a fixed space tied into the frame (I think). But there are tricks I guess. Anyway, I hadn't seen this idea before. Seems Regards, Bengt Richter > >On 2/20/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: >> I am considering developing a PEP for enabling a mechanism to assign to free >> variables in a closure (nested function). My rationale is that with the >> advent of PEP 227 , Python has proper nested lexical scopes, but can have >> undesirable behavior (especially with new developers) when a user makes >> wants to make an assignment to a free variable within a nested function. >> Furthermore, after seeing numerous kludges to "solve" the problem with a >> mutable object, like a list, as the free variable do not seem "Pythonic." I >> have also seen mention that the use of classes can mitigate this, but that >> seems, IMHO, heavy handed in cases when an elegant solution using a closure >> would suffice and be more appropriate--especially when Python already has >> nested lexical scopes. >> >> I propose two possible approaches to solve this issue: >> >> 1. Adding a keyword such as "use" that would follow similar semantics as >> "global" does today. A nested scope could declare names with this keyword >> to enable assignment to such names to change the closest parent's binding. >> The semantic would be to keep the behavior we experience today but tell the >> compiler/interpreter that a name declared with the "use" keyword would >> explicitly use an enclosing scope. I personally like this approach the most >> since it would seem to be in keeping with the current way the language works >> and would probably be the most backwards compatible. The semantics for how >> this interacts with the global scope would also need to be defined (should >> "use" be equivalent to a global when no name exists all parent scopes, etc.) >> >> >> def incgen( inc = 1 ) : >>a = 6 >>def incrementer() : >> use a >> #use a, inc <-- list of names okay too >> a += inc >> return a >>return incrementer >> >> Of course, this approach suffers from a downside that every nested scope >> that wanted to assign to a parent scope's name would need to have the "use" >> keyword for those names--but one could argue that this is in keeping with >> one of Python's philosophies that "Explicit is better than implicit" (PEP >> 20). This approach also has to deal with a user declaring a name with " >> use" that is a named parameter--this would be a semantic error that could be >> handled like "global " does today with a SyntaxError. >> >> 2. Adding a keyword such as "scope" that would behave similarly to >> JavaScript's " var" keyword. A name c
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
I had to lookup top-post :-). On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> wrote: > >Jeremy > Hey, only Guido is allowed to top-post. He said so ;-) The Gmail UI makes it really easy to forget where the q > But to the topic, it just occurred to me that any outer scopes could be given > names > (including global namespace, but that would have the name global by default, > so > global.x would essentially mean what globals()['x'] means now, except it would > be a name error if x didn't pre-exist when accessed via > namespace_name.name_in_space notation. > > > namespace g_alias # g_alias.x becomes alternate spelling of global.x > def outer(): > namespace mezzanine > a = 123 > print a # => 123 > print mezzanine.a # => 123 (the name space name is visible and > functional locally) > def inner(): > print mezzanine.a => 123 > mezznine.a =456 > inner() > print a # = 456 > global.x = re-binds global x, name error if not preexisting. > > This would allow creating mezzanine like an attribute view of the slots in > that local namespace, > as well as making namespace itself visible there, so the access to mezzanine > would look like a read access to > an ordinary object named mezzanine that happened to have attribute slots > matching outer's local name space. > > Efficiency might make it desirable not to extend named namespaces with new > names, function locals being > slotted in a fixed space tied into the frame (I think). But there are tricks > I guess. > Anyway, I hadn't seen this idea before. Seems > > Regards, > Bengt Richter > > > > >On 2/20/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: > >> I am considering developing a PEP for enabling a mechanism to assign to > >> free > >> variables in a closure (nested function). My rationale is that with the > >> advent of PEP 227 , Python has proper nested lexical scopes, but can have > >> undesirable behavior (especially with new developers) when a user makes > >> wants to make an assignment to a free variable within a nested function. > >> Furthermore, after seeing numerous kludges to "solve" the problem with a > >> mutable object, like a list, as the free variable do not seem "Pythonic." > >> I > >> have also seen mention that the use of classes can mitigate this, but that > >> seems, IMHO, heavy handed in cases when an elegant solution using a closure > >> would suffice and be more appropriate--especially when Python already has > >> nested lexical scopes. > >> > >> I propose two possible approaches to solve this issue: > >> > >> 1. Adding a keyword such as "use" that would follow similar semantics as > >> "global" does today. A nested scope could declare names with this keyword > >> to enable assignment to such names to change the closest parent's binding. > >> The semantic would be to keep the behavior we experience today but tell the > >> compiler/interpreter that a name declared with the "use" keyword would > >> explicitly use an enclosing scope. I personally like this approach the > >> most > >> since it would seem to be in keeping with the current way the language > >> works > >> and would probably be the most backwards compatible. The semantics for how > >> this interacts with the global scope would also need to be defined (should > >> "use" be equivalent to a global when no name exists all parent scopes, > >> etc.) > >> > >> > >> def incgen( inc = 1 ) : > >>a = 6 > >>def incrementer() : > >> use a > >> #use a, inc <-- list of names okay too > >> a += inc > >> return a > >>return incrementer > >> > >> Of course, this approach suffers from a downside that every nested scope > >> that wanted to assign to a parent scope's name would need to have the "use" > >> keyword for those names--but one could argue that this is in keeping with > >> one of Python's philosophies that "Explicit is better than implicit" (PEP > >> 20). This approach also has to deal with a user declaring a name with " > >> use" that is a named parameter--this would be a semantic error that could > >> be > >> handled like "global " does today with a SyntaxError. > >> > >> 2. Adding a keyword such as "scope" that would behave similarly to > >> JavaScript's " var" keyword. A name could be declared with such a keyword > >> optionally and all nested scopes would use the declaring scope's binding > >> when accessing or assigning to a particular name. This approach has > >> similar > >> benefits to my first approach, but is clearly more top-down than the first > >> approach. Subsequent "scope" declarations would create a new binding at > >> the > >> declaring scope for the declaring and child scopes to use. This could > >> potentially be a gotcha for users expecting the binding semantics in place > >> today. Also the scope keyword would have to be allowed to be
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > I had to lookup top-post :-). > > On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > > On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> > > wrote: > > >Jeremy > > Hey, only Guido is allowed to top-post. He said so ;-) > > The Gmail UI makes it really easy to forget where the q Sorry about that. Hit the send key by mistake. The Gmail UI makes it really easy to forget where the quoted text is in relation to your own text. > > But to the topic, it just occurred to me that any outer scopes could be > > given names > > (including global namespace, but that would have the name global by > > default, so > > global.x would essentially mean what globals()['x'] means now, except it > > would > > be a name error if x didn't pre-exist when accessed via > > namespace_name.name_in_space notation. Isn't this suggestion that same as Greg Ewing's? > > namespace g_alias # g_alias.x becomes alternate spelling of global.x > > def outer(): > > namespace mezzanine > > a = 123 > > print a # => 123 > > print mezzanine.a # => 123 (the name space name is visible and > > functional locally) > > def inner(): > > print mezzanine.a => 123 > > mezznine.a =456 > > inner() > > print a # = 456 > > global.x = re-binds global x, name error if not preexisting. > > > > This would allow creating mezzanine like an attribute view of the slots in > > that local namespace, > > as well as making namespace itself visible there, so the access to > > mezzanine would look like a read access to > > an ordinary object named mezzanine that happened to have attribute slots > > matching outer's local name space. I don't think using attribute access is particularly clear here. It introduces an entirely new concept, a first-class namespace, in order to solve a small scoping problem. It looks too much like attribute access and not enough like accessing a variable. Jeremy > > Efficiency might make it desirable not to extend named namespaces with new > > names, function locals being > > slotted in a fixed space tied into the frame (I think). But there are > > tricks I guess. > > Anyway, I hadn't seen this idea before. Seems > > > > Regards, > > Bengt Richter > > > > > > > >On 2/20/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: > > >> I am considering developing a PEP for enabling a mechanism to assign to > > >> free > > >> variables in a closure (nested function). My rationale is that with the > > >> advent of PEP 227 , Python has proper nested lexical scopes, but can have > > >> undesirable behavior (especially with new developers) when a user makes > > >> wants to make an assignment to a free variable within a nested function. > > >> Furthermore, after seeing numerous kludges to "solve" the problem with a > > >> mutable object, like a list, as the free variable do not seem > > >> "Pythonic." I > > >> have also seen mention that the use of classes can mitigate this, but > > >> that > > >> seems, IMHO, heavy handed in cases when an elegant solution using a > > >> closure > > >> would suffice and be more appropriate--especially when Python already has > > >> nested lexical scopes. > > >> > > >> I propose two possible approaches to solve this issue: > > >> > > >> 1. Adding a keyword such as "use" that would follow similar semantics > > >> as > > >> "global" does today. A nested scope could declare names with this > > >> keyword > > >> to enable assignment to such names to change the closest parent's > > >> binding. > > >> The semantic would be to keep the behavior we experience today but tell > > >> the > > >> compiler/interpreter that a name declared with the "use" keyword would > > >> explicitly use an enclosing scope. I personally like this approach the > > >> most > > >> since it would seem to be in keeping with the current way the language > > >> works > > >> and would probably be the most backwards compatible. The semantics for > > >> how > > >> this interacts with the global scope would also need to be defined > > >> (should > > >> "use" be equivalent to a global when no name exists all parent scopes, > > >> etc.) > > >> > > >> > > >> def incgen( inc = 1 ) : > > >>a = 6 > > >>def incrementer() : > > >> use a > > >> #use a, inc <-- list of names okay too > > >> a += inc > > >> return a > > >>return incrementer > > >> > > >> Of course, this approach suffers from a downside that every nested scope > > >> that wanted to assign to a parent scope's name would need to have the > > >> "use" > > >> keyword for those names--but one could argue that this is in keeping with > > >> one of Python's philosophies that "Explicit is better than implicit" (PEP > > >> 20). This approach also has to deal with a user declaring a name with " > > >> use" that is a named parameter--this would be a semantic error that > > >> could
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
> But to the topic, it just occurred to me that any outer scopes could be given > names > (including global namespace, but that would have the name global by default, > so > global.x would essentially mean what globals()['x'] means now, except it would > be a name error if x didn't pre-exist when accessed via > namespace_name.name_in_space notation. > > > namespace g_alias # g_alias.x becomes alternate spelling of global.x > def outer(): > namespace mezzanine > a = 123 > print a # => 123 > print mezzanine.a # => 123 (the name space name is visible and > functional locally) > def inner(): > print mezzanine.a => 123 > mezznine.a =456 > inner() > print a # = 456 > global.x = re-binds global x, name error if not preexisting. > > This would allow creating mezzanine like an attribute view of the slots in > that local namespace, > as well as making namespace itself visible there, so the access to mezzanine > would look like a read access to > an ordinary object named mezzanine that happened to have attribute slots > matching outer's local name space. > This seems like a neat idea in principle, but I wonder if it removes consistency from the language.Consider that the scope that declares the namespace and its child scopes the names could be accessed by the namespace object or the direct name, but *only* in the child scopes can re-binding for the name be done via the namespace object. def outer() : namespace n a = 5 # <-- same as n.a = 5 def inner() : print a # <-- same as n.a n.a = 7 # <-- *not* the same as a = 7 print n.a I don't like how a child scope can access a free variable from an enclosing scope without the namespace object, but needs to use it for re-binding. Because of this, namespace objects have the potential to obfuscate things more than fix the language issue that I am addressing. -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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 for Better Control of Nested Lexical Scopes
Jeremy Hylton wrote: > On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: >> I had to lookup top-post :-). >> >> On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote: >>> On Tue, 21 Feb 2006 08:02:08 -0500, "Jeremy Hylton" <[EMAIL PROTECTED]> >>> wrote: Jeremy >>> Hey, only Guido is allowed to top-post. He said so ;-) >> The Gmail UI makes it really easy to forget where the q > > Sorry about that. Hit the send key by mistake. > > The Gmail UI makes it really easy to forget where the quoted text is > in relation to your own text. > >>> But to the topic, it just occurred to me that any outer scopes could be >>> given names >>> (including global namespace, but that would have the name global by >>> default, so >>> global.x would essentially mean what globals()['x'] means now, except it >>> would >>> be a name error if x didn't pre-exist when accessed via >>> namespace_name.name_in_space notation. > > Isn't this suggestion that same as Greg Ewing's? > >>> namespace g_alias # g_alias.x becomes alternate spelling of global.x >>> def outer(): >>> namespace mezzanine >>> a = 123 >>> print a # => 123 >>> print mezzanine.a # => 123 (the name space name is visible and >>> functional locally) >>> def inner(): >>> print mezzanine.a => 123 >>> mezznine.a =456 >>> inner() >>> print a # = 456 >>> global.x = re-binds global x, name error if not preexisting. >>> >>> This would allow creating mezzanine like an attribute view of the slots in >>> that local namespace, >>> as well as making namespace itself visible there, so the access to >>> mezzanine would look like a read access to >>> an ordinary object named mezzanine that happened to have attribute slots >>> matching outer's local name space. Why not just use a class? def incgen(start=0, inc=1) : class incrementer(object): a = start - inc def __call__(self): self.a += inc return self.a return incrementer() a = incgen(7, 5) for n in range(10): print a(), 7 12 17 22 27 32 37 42 47 52 Cheers, Ronald Adam ___ 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] Deprecate ``multifile``?
On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote: > Fredrik Lundh wrote: > > Georg Brandl wrote: > > > >> as Jim Jewett noted, multifile is supplanted by email as much as mimify > >> etc. > >> but it is not marked as deprecated. Should it be deprecated in 2.5? > > > > -0.5 (gratuitous breakage). > > > > I think the current "see also/supersedes" link is good enough. > > Well, it would be deprecated like the other email modules, that is, only > a note is added to the docs and it is added to PEP 4. There would be no > warning. IIRC, when I brought this up ages ago, there was some grumbling that multifile is useful for other than email/MIME applications. Still, I'm +1 on PEP 4'ing it. -Barry signature.asc Description: This is a digitally signed message part ___ 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] defaultdict proposal round three
On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote: ... > Just one more thing -- have you made a final decision > about the name yet? I'd still prefer something like > 'autodict', because to me 'defaultdict' suggests autodict is shorter and sharper and I prefer it, too: +1 > etc.) it seems more accurate to think of the value > produced by the factory as an 'initial value' rather > than a 'default value', and I'd prefer to see it If we call the type autodict, then having the factory attribute named autofactory seems to fit. This leaves it open to the reader's imagination to choose whether to think of the value as "initial" or "default" -- it's the *auto* (automatic) value. Alex ___ 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] defaultdict proposal round three
Guido van Rossum wrote: >On 2/21/06, Fuzzyman <[EMAIL PROTECTED]> wrote: > > >>I've had problems in code that needs to treat strings, lists and >>dictionaries differently (assigning values to a container where all >>three need different handling) and telling the difference but allowing >>duck typing is *problematic*. >> >> > >Consider designing APIs that don't require you to mae that kind of >distinction, if you're worried about edge cases and classifying >arbitrary other objects correctly. It's totally possible to create an >object that behaves like a hybrid of a string and a dict. > > > Understood. >If you're only interested in classifying the three specific built-ins >you mention, I'd check for the presense of certain attributes: >hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort") >-> x is a list; hasattr(x, "update") -> x is a dict. Also, hasattr(x, >"union") -> x is a set; hasattr(x, "readline") -> x is a file. > >That's duck typing! > > Sure, but that requires a "dictionary like object" to define an update method, and a "list like object" to define a sort method. The mapping and sequence protocols are so loosely defined that some arbitrary decision like this has to be made. (Any object that defines "__getitem__" could follow either or both and duck typing doesn't help you unless you're prepared to make an additional requirement that is outside the loose requirements of the protocol.) I can't remember how we solved it, but I think we decided that an object would be treated as a string if it passed isinstance, and a dictionary or sequence if it has _getitem__ (but isn't a string instance or subclass). If it has update as well as __getitem__ it is a "dictionary-alike". All the best, Michael Foord >-- >--Guido van Rossum (home page: http://www.python.org/~guido/) > > > ___ 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 for Better Control of Nested Lexical Scopes
Greg Ewing wrote: >def my_func(): > namespace foo > foo.x = 42 > > def inc_x(): >foo.x += 1 > > The idea here is that foo wouldn't be an object in > its own right, but just a collection of names that > would be implemented as local variables of my_func. But why is that better than class namespace(object): pass def my_func(): foo = namespace() (...) ? Georg ___ 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 for Better Control of Nested Lexical Scopes
> Why not just use a class? > > > def incgen(start=0, inc=1) : > class incrementer(object): > a = start - inc > def __call__(self): > self.a += inc > return self.a > return incrementer() > > a = incgen(7, 5) > for n in range(10): > print a(), Because I think that this is a workaround for a concept that the language doesn't support elegantly with its lexically nested scopes. IMO, you are emulating name rebinding in a closure by creating an object to encapsulate the name you want to rebind--you don't need this workaround if you only need to access free variables in an enclosing scope. I provided a "lighter" example that didn't need a callable object but could use any mutable such as a list. This kind of workaround is needed as soon as you want to re-bind a parent scope's name, except in the case when the parent scope is the global scope (since there is the "global" keyword to handle this). It's this dichotomy that concerns me, since it seems to be against the elegance of Python--at least in my opinion. It seems artificially limiting that enclosing scope name rebinds are not provided for by the language especially since the behavior with the global scope is not so. In a nutshell I am proposing a solution to make nested lexical scopes to be orthogonal with the global scope and removing a "wart," as Jeremy put it, in the language. -Almann -- Almann T. Goo [EMAIL PROTECTED] ___ 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] Removing Non-Unicode Support?
M.-A. Lemburg wrote: > Note that I'm not saying that these switches are useless - of > course they do allow to strip down the Python interpreter. > I believe that only very few people are interested in having these > options and it's fair enough to put the burden of maintaining these > branches on them. Which is proven by the fact that many tests fail without unicode. So at least the people building --without-unicode don't care much about brokenness. Georg ___ 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] buildbot vs. Windows
"Neal Norwitz" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > There's nothing to prevent buildbot from making debug builds, though > that is not currently done. Now that there are separate report pages for 2.4 and 2.5, you could add pages for debug builds, perhaps with a lower frequency (once a day?), without cluttering up the main two pages. ___ 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] defaultdict proposal round three
On 2/21/06, Alex Martelli <[EMAIL PROTECTED]> wrote: > > On Feb 21, 2006, at 1:51 AM, Greg Ewing wrote: > ... > > Just one more thing -- have you made a final decision > > about the name yet? I'd still prefer something like > > 'autodict', because to me 'defaultdict' suggests > > autodict is shorter and sharper and I prefer it, too: +1 Apart from it somehow hashing to the same place as "autodidact" in my brain :), I don't like it as much.; someone who doesn't already know what it is doesn't have a clue what an "automatic dictionary" would offer compared to a regular one. IMO "default" conveys just enough of a hint that something is being defaulted. A name long enough to convey all the details of why, when, and it defaults wouldn't be practical. (Look up the history of botanical names under Linnaeus for a simile.) I'll let it brew in SF for a while but I expect to be checking this in at PyCon. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Deprecate ``multifile``?
Barry Warsaw wrote: > On Fri, 2006-02-17 at 14:01 +0100, Georg Brandl wrote: >> Fredrik Lundh wrote: >> > Georg Brandl wrote: >> > >> >> as Jim Jewett noted, multifile is supplanted by email as much as mimify >> >> etc. >> >> but it is not marked as deprecated. Should it be deprecated in 2.5? >> > >> > -0.5 (gratuitous breakage). >> > >> > I think the current "see also/supersedes" link is good enough. >> >> Well, it would be deprecated like the other email modules, that is, only >> a note is added to the docs and it is added to PEP 4. There would be no >> warning. > > IIRC, when I brought this up ages ago, there was some grumbling that > multifile is useful for other than email/MIME applications. Still, I'm > +1 on PEP 4'ing it. Which means "go ahead" or "wait for others to be -1"? Georg ___ 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] defaultdict proposal round three
On Tue, 21 Feb 2006 05:58:52 -0800, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: >On 2/20/06, Bengt Richter <[EMAIL PROTECTED]> wrote: >> How about doing it as an expression, empowering ( ;-) the dict just afer >> creation? >> E.g., for >> >> d = dict() >> d.default_factory = list >> >> you could write >> >> d = dict()**list > >Bengt, can you let your overactive imagination rest for a while? I >recommend that you sit back, relax for a season, and reflect on the >zen nature of Pythonicity. Then come back and hopefully you'll be able >to post without embarrassing yourself continuously. > It is tempting to seek vindication re "embarrassing yourself continuously" but I'll let it go, and treat it as an opportunity to explore the nature of my ego a little further ;-) I am not embarrassed by having an "overactive imagination," thank you, but if it is causing a problem for you here, I apologize, and will withdraw. Thanks for the nudge. I really have been wasting a lot of time using python trivial pursuits as an escape from tackling stuff that I haven't been ready for. It's time I focus. Thanks, and good luck. I'll be off now ;-) Regards, Bengt Richter ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]
Greg Ewing wrote: > Ron Adam wrote: > >> Storing byte information as 16 or 32 bits ints could take up a rather >> lot of memory in some cases. > > I don't quite see the point here. Inside a bytes object, > they would be stored 1 byte per byte. Nobody is suggesting > that they would take up more than that just because > a_bytes_object[i] happens to return an int. Yes, and the above is the obvious reason why not. Not that I thought it was being considered. > So the only reason to introduce a new "byte" type is to > remove some of the operations that int has. We can already > do bitwise operations on an int, so we don't need a new > type to add that capability. Yes, and a byte type isn't needed if the individual bytes are always in a bytes object. A bytes object with a single byte would be an octet in that case. > What's more, I can see this leading to people asking for > arithmetic operations to be *added* to the byte type so > they can do wrap-around arithmetic, and then for 16-bit, > 32-bit, 64-bit etc. versions of it, etc. etc. I agree the bytes object shouldn't re implement arithmetic. I would like bitwise logic operations on bytes() and byte ranges() if possible. Cheers, Ronald Adam ___ 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] Deprecate ``multifile``?
On Tue, 2006-02-21 at 17:18 +0100, Georg Brandl wrote: > > IIRC, when I brought this up ages ago, there was some grumbling that > > multifile is useful for other than email/MIME applications. Still, I'm > > +1 on PEP 4'ing it. > > Which means "go ahead" or "wait for others to be -1"? s/or/and/ ? :) I say go ahead and add it to PEP 4. -Barry signature.asc Description: This is a digitally signed message part ___ 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] A codecs nit
On Sat, 2006-02-18 at 14:44 +0100, M.-A. Lemburg wrote: > In Py 2.5 we'll change that. The encodings package search > function will only allow codecs in that package to be > imported. All other codec packages will have to provide > their own search function and register this with the > codecs registry. My weekend experimentation used the imp functions to constrain the module search path to encodings.__path__, but I'm not sure that's much better than prepending 'encodings.' on the module name and letting __import__() do its thing. > The big question is: what to do about 2.3 and 2.4 - adding > the same patch will cause serious breakage, since popular > codec packages such as Tamito's Japanese package rely > on the existing behavior. FWIW, Mailman has had to do a bunch of special case loading of the 3rd party Japanese and Korean codecs for older Pythons, and the email package also has to do special tests for e.g. euc-jp before it'll do the Asian codec tests. I think most of the latter is unnecessary for 2.4 and beyond, and I suspect that the former is also unnecessary for 2.4 and beyond. It's probably still necessary for 2.3. IIUC, there are still people who prefer Tamito's package over the built-in Japanese codecs in 2.4, but I don't understand all the details. My preference would be to backport the fix to 2.4 but not worry about 2.3 since there are no plans to ever release a 2.3.6 AFAIK. -Barry signature.asc Description: This is a digitally signed message part ___ 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 for Better Control of Nested Lexical Scopes
Almann T. Goo <[EMAIL PROTECTED]> wrote: >> 1. Adding a keyword such as "use" that would follow similar semantics as " >> global" does today. A nested scope could declare names with this keyword >> to enable assignment to such names to change the closest parent's binding. +0, and I like "outer". I like the idea, but I grepped several Python programs I wrote, and found out that I used the list trick many times, but almost always in quick-hack code in unittests. I wasn't able to find a single instance of this in real code I wrote, so I can't really be +1. -- Giovanni Bajo ___ 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] bytes.from_hex()
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Stephen J. Turnbull wrote: > > > What I advocate for Python is to require that the standard base64 > > codec be defined only on bytes, and always produce bytes. > > I don't understand that. It seems quite clear to me that > base64 encoding (in the general sense of encoding, not the > unicode sense) takes binary data (bytes) and produces characters. > That's the whole point of base64 -- so you can send arbitrary > data over a channel that is only capable of dealing with > characters. > > So in Py3k the correct usage would be > >base64unicode >encodeencode(x) >original bytes > unicode -> bytes for transmission > < <- >base64unicode >decodedecode(x) > > where x is whatever unicode encoding the transmission > channel uses for characters (probably ascii or an ascii > superset, but not necessarily). It doesn't seem strange to you to need to encode data twice to be able to have a usable sequence of characters which can be embedded in an effectively 7-bit email; when base64 was, dare I say it, designed to have 7-bit email as its destination in the first place? It does to me. - Josiah ___ 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] defaultdict proposal round three
>> > Just one more thing -- have you made a final decision >> > about the name yet? I'd still prefer something like >> > 'autodict', because to me 'defaultdict' suggests >> >> autodict is shorter and sharper and I prefer it, too: +1 > > Apart from it somehow hashing to the same place as "autodidact" in my > brain :), I don't like it as much.; someone who doesn't already know > what it is doesn't have a clue what an "automatic dictionary" would > offer compared to a regular one. IMO "default" conveys just enough of > a hint that something is being defaulted. A name long enough to convey > all the details of why, when, and it defaults wouldn't be practical. > (Look up the history of botanical names under Linnaeus for a simile.) I'm with Guido on this one. The word default is closely associated with what makes this different from regular dictionaries and it is closely associated with the name of the attribute, default_factory. Also, the word has a history of parallel use in the context of dict.get(). The word "auto" on the other hand is associated with nothing. You might as well argue to call it magicdictionary because "magic" has two letters less than "default" ;-) Raymond ___ 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 for Better Control of Nested Lexical Scopes
"Almann T. Goo" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I certainly hope that an initiative like this doesn't get stymied by > the lack of a good name for such a keyword. Maybe something like > "outer"? Adding a keyword has a cost that you have so far ignored. Guido is rightfully very cautious about additions, especially for esthetic reasons. The issue of rebinding enclosed names was partly discussed in PEP 227. Sometime after the implementation of the PEP in 2.1, it was thoroughly discussed again (100+ posts?) in this forum. There were perhaps 10 different proposals, including, I believe, 'outer'. Guido rejected them all as having costs greater than the benefits. Perhaps you can find this discussion in the archives. I remember it as a Jan-Feb discussion but might be wrong. This thread so far seems like a rehash of parts of the earlier discussion. In the absence of indication from Guido that he is ready to reopen the issue, perhaps it would better go to comp.lang.python. In and case, reconsideration is more likely to be stimulated by new experience with problems in real code than by repeats of 'orthogonality' desires and rejected changes. --- In another post, you rejected the use of class instances by opining: >Because I think that this is a workaround for a concept that the >language doesn't support elegantly with its lexically nested scopes. >IMO, you are emulating name rebinding in a closure by creating an >object to encapsulate the name you want to rebind Guido, on the other hand, views classes and instances as Python's method of doing what other (functional) languages do with closures. From the PEP: "Given that this would encourage the use of local variables to hold state that is better stored in a class instance, it's not worth adding new syntax to make this possible (in Guido's opinion)." He reiterated this viewpoint in the post-PEP discussion mentioned above. I think he would specificly reject the view that Python's alternative is a 'workaround' and 'emulation' of what you must consider to be the real thing. 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] PEP for Better Control of Nested Lexical Scopes
On 2/21/06, Terry Reedy <[EMAIL PROTECTED]> wrote: > > "Almann T. Goo" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > > > I certainly hope that an initiative like this doesn't get stymied by > > the lack of a good name for such a keyword. Maybe something like > > "outer"? > > Adding a keyword has a cost that you have so far ignored. Guido is > rightfully very cautious about additions, especially for esthetic reasons. > > The issue of rebinding enclosed names was partly discussed in PEP 227. > Sometime after the implementation of the PEP in 2.1, it was thoroughly > discussed again (100+ posts?) in this forum. There were perhaps 10 > different proposals, including, I believe, 'outer'. Guido rejected them > all as having costs greater than the benefits. Perhaps you can find this > discussion in the archives. I remember it as a Jan-Feb discussion but > might be wrong. If I recall the discussion correctly, Guido said he was open to a version of nested scopes that allowed rebinding. Not sure that the specifics of the previous discussion are necessary, but I recall being surprised by the change in opinion since 2.1 :-). Jeremy > > This thread so far seems like a rehash of parts of the earlier discussion. > In the absence of indication from Guido that he is ready to reopen the > issue, perhaps it would better go to comp.lang.python. In and case, > reconsideration is more likely to be stimulated by new experience with > problems in real code than by repeats of 'orthogonality' desires and > rejected changes. > > --- > > In another post, you rejected the use of class instances by opining: > > >Because I think that this is a workaround for a concept that the > >language doesn't support elegantly with its lexically nested scopes. > > >IMO, you are emulating name rebinding in a closure by creating an > >object to encapsulate the name you want to rebind > > Guido, on the other hand, views classes and instances as Python's method of > doing what other (functional) languages do with closures. From the PEP: > "Given that this > would encourage the use of local variables to hold state that is > better stored in a class instance, it's not worth adding new > syntax to make this possible (in Guido's opinion)." > He reiterated this viewpoint in the post-PEP discussion mentioned above. I > think he would specificly reject the view that Python's alternative is a > 'workaround' and 'emulation' of what you must consider to be the real > thing. > > 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/jeremy%40alum.mit.edu > ___ 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] Deprecate ``multifile``?
Barry Warsaw wrote: > On Tue, 2006-02-21 at 17:18 +0100, Georg Brandl wrote: > >> > IIRC, when I brought this up ages ago, there was some grumbling that >> > multifile is useful for other than email/MIME applications. Still, I'm >> > +1 on PEP 4'ing it. >> >> Which means "go ahead" or "wait for others to be -1"? > > s/or/and/ ? :) > > I say go ahead and add it to PEP 4. Done, and added a note in the docs. More will not be needed until 3.0, I suppose. Georg ___ 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] defaultdict proposal round three
Then you will likely be happy with Guido's current version of the patch. - Original Message - From: "Crutcher Dunnavant" <[EMAIL PROTECTED]> To: "Raymond Hettinger" <[EMAIL PROTECTED]> Cc: "Python Dev" Sent: Monday, February 20, 2006 8:57 PM Subject: Re: [Python-Dev] defaultdict proposal round three in two ways: 1) dict.get doesn't work for object dicts or in exec/eval contexts, and 2) dict.get requires me to generate the default value even if I'm not going to use it, a process which may be expensive. On 2/20/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Crutcher Dunnavant ] > >> There are many times that I want d[key] to give me a value even when > >> it isn't defined, but that doesn't always mean I want to _save_ that > >> value in the dict. > > How does that differ from the existing dict.get method? > > > Raymond > -- 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 for Better Control of Nested Lexical Scopes
Greg Ewing <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > > Mechanisms which rely on manipulating variables within closures or > > nested scopes to function properly can be elegant, but I've not yet seen > > one that *really* is. > > It seems a bit inconsistent to say on the one hand > that direct assignment to a name in an outer scope > is not sufficiently useful to be worth supporting, > while at the same time providing a way to do it for > one particular scope, i.e. 'global'. Would you > advocate doing away with it? I didn't conceive of the idea or implementation of 'global', it was before my time. I have found that *using* global can be convenient (and sometimes even directly manipulating globals() can be even more convenient). However, I believe global was and is necessary for the same reasons for globals in any other language. Are accessors for lexically nested scopes necessary? Obviously no. The arguments for their inclusion are: easier access to parent scopes and potentially faster execution. The question which still remains in my mind, which I previously asked, is whether the use cases are compelling enough to warrant the feature addition. > > Of course using > > classes directly with a bit of work can offer you everything you want > > from a closure, with all of the explcitness that you could ever want. > > There are cases where the overhead (in terms of amount > of code) of defining a class and creating an instance of > it swamps the code which does the actual work, and, > I feel, actually obscures what is being done rather > than clarifies it. These cases benefit from the ability > to refer to names in enclosing scopes, and I believe > they would benefit further from the ability to assign > to such names. class namespace: pass def fcn(...): foo = namespace() ... Overwhelms the user? > Certainly the feature could be abused, as can the > existing nested scope facilities, or any other language > feature for that matter. Mere potential for abuse is > not sufficient reason to reject a feature, or the > language would have no features at all. Indeed, but as I have asked, I would like to see some potential nontrivial *uses*. No one has responded to this particular request. When I am confronted with a lack of uses, and the potential for abuses, I'm going to have to side on "no thanks, the potential abuse outweighs the nonexistant nontrivial use". > Another consideration is efficiency. CPython currently > implements access to local variables (both in the > current scope and all outer ones except the module > scope) in an extremely efficient way. There's > always the worry that using attribute access in > place of local variable access is greatly increasing > the runtime overhead for no corresponding benefit. Indeed, the only benefit to using classes is that you gain explicitness. To gain speed in current Python, one may need to do a bit more work (slots, call frame hacking, perhaps an AST manipulation with the new AST branch, etc.). > You mention the idea of namespaces. Maybe an answer > is to provide some lightweight way of defining a > temporary, singe-use namespace for use within > nested scopes -- lightweight in terms of both code > volume and runtime overhead. Perhaps something like > >def my_func(): > namespace foo > foo.x = 42 > > def inc_x(): >foo.x += 1 Because this discussion is not about "how do I create a counter in Python", let's see some examples which are not counters and which are improved through the use of this "namespace", or "use", "scope", etc. > > Introducing these two new keywords is equivalent to > > encouraging nested scope use. Right now nested scope > > use is "limited" or "fraught with gotchas". > > What you seem to be saying here is: Nested scope use > is Inherently Bad. Therefore we will keep them Limited > and Fraught With Gotchas, so people will be discouraged > from using them. > > Sounds a bit like the attitude of certain religious > groups to condoms. (Might encourage people to have > sex -- can't have that -- look at all the nasty diseases > you can get!) If you take that statement within the context of the other things I had been saying in regards to closures and nested scopes, namely that I find their use rarely, if ever, truely elegant, it becomes less like "condom use" as purported by some organizations, and more like kicking a puppy for barking: it is of my opinion that there are usually better ways of dealing with the problem (don't kick puppies for barking and don't use closures). - Josiah ___ 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] Stateful codecs [Was: str object going in Py3K]
Hye-Shik Chang wrote: > On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: >> M.-A. Lemburg wrote: >>> Walter Dörwald wrote: Anyway, I've started implementing a patch that just adds codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig, UTF-16, UTF-16-LE and UTF-16-BE are already working. >>> Nice :-) >> gencodec.py is updated now too. The rest should be manageble too. >> I'll leave updating the CJKV codecs to Hye-Shik though. > > Okay. I'll look whether how CJK codecs can be improved by the > new protocol soon. I guess it'll be not so difficult because CJK > codecs have a their own common stateful framework already. OK, here's the patch: bugs.python.org/1436130 (assigned to MAL). > BTW, CJK codecs don't have V yet. :-) Bye, Walter Dörwald ___ 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] Stateful codecs [Was: str object going in Py3K]
Walter Dörwald wrote: > Hye-Shik Chang wrote: > >> On 2/19/06, Walter Dörwald <[EMAIL PROTECTED]> wrote: >>> M.-A. Lemburg wrote: Walter Dörwald wrote: > Anyway, I've started implementing a patch that just adds > codecs.StatefulEncoder/codecs.StatefulDecoder. UTF8, UTF8-Sig, > UTF-16, UTF-16-LE and UTF-16-BE are already working. Nice :-) >>> gencodec.py is updated now too. The rest should be manageble too. >>> I'll leave updating the CJKV codecs to Hye-Shik though. >> >> Okay. I'll look whether how CJK codecs can be improved by the >> new protocol soon. I guess it'll be not so difficult because CJK >> codecs have a their own common stateful framework already. > > OK, here's the patch: bugs.python.org/1436130 (assigned to MAL). Thanks. I won't be able to look into it this week though, probably next week. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 21 2006) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
At 11:31 AM 2/21/2006 -0800, Josiah Carlson wrote: >Greg Ewing <[EMAIL PROTECTED]> wrote: > > > > It seems a bit inconsistent to say on the one hand > > that direct assignment to a name in an outer scope > > is not sufficiently useful to be worth supporting, > > while at the same time providing a way to do it for > > one particular scope, i.e. 'global'. Would you > > advocate doing away with it? > >I didn't conceive of the idea or implementation of 'global', it was >before my time. I have found that *using* global can be convenient (and >sometimes even directly manipulating globals() can be even more >convenient). However, I believe global was and is necessary for the >same reasons for globals in any other language. Here's a crazy idea, that AFAIK has not been suggested before and could work for both globals and closures: using a leading dot, ala the new relative import feature. e.g.: def incrementer(val): def inc(): .val += 1 return .val return inc The '.' would mean "this name, but in the nearest outer scope that defines it". Note that this could include the global scope, so the 'global' keyword could go away in 2.5. And in Python 3.0, the '.' could become *required* for use in closures, so that it's not necessary for the reader to check a function's outer scope to see whether closure is taking place. EIBTI. Interestingly, the absence of a name before the dot seems to imply that the name is an attribute of the Unnameable. :) Or more prosaically, it treats lexical closures and module globals as special cases of objects. You could perhaps even extend it so that '.' by itself means the same thing as vars(), but that's probably going too far, assuming that the idea wasn't too far gone to begin with. I suspect functional folks will love the '.' idea, but also that folks who wanted to get rid of 'self' will probably scream bloody murder at the idea of using a leading dot to represent a scope intead of 'self'. :) ___ 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 343 "with" statement patch
With Neal Norwitz's help, I've submitted an initial patch to implement the "with" statement from PEP 343 (SourceForge request ID 1435715). There is a little more work to be done (on the doc especially), and I have a couple of questions written up on the SourceForge page, but the code works to the best of my understanding of PEP 343 and has a fairly comprehensive set of unit tests to verify it. Looking forward to the review, Mike ___ 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 for Better Control of Nested Lexical Scopes
On 21 Feb 2006, at 19:25, Jeremy Hylton wrote:
> If I recall the discussion correctly, Guido said he was open to a
> version of nested scopes that allowed rebinding.
PEP 227 mentions using := as a rebinding operator, but rejects the
idea as it would encourage the use of closures. But to me it seems
more elegant than some special keyword, especially is it could also
replace the "global" keyword. It doesn't handle things like "x += y"
but I think you could deal with that by just writing "x := x + y".
BTW I do think there are some cases where replacing a closure with a
class is not an improvement. For example (and assuming the existence
of :=):
def check_items(items):
had_error = False
def err(mesg):
print mesg
had_error := True
for item in items:
if too_big(item):
err("Too big")
if too_small(item):
err("Too small")
if had_error:
print "Some items were out of range"
Using a class for this kind of trivial bookkeeping just adds
boilerplate and obscures the main purpose of the code:
def check_items(items):
class NoteErrors (object):
def __init__(self):
self.had_error = False
def __call__(self, mesg):
print mesg
self.had_error = True
err = NoteErrors()
for item in items:
if too_big(item):
err("Too big")
if too_small(item):
err("Too small")
if err.had_error:
print "Some items were out of range"
Any chance of := (and removing "global") in python 3K?
Mark Russell
___
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 for Better Control of Nested Lexical Scopes
Mark Russell wrote: > PEP 227 mentions using := as a rebinding operator, but rejects the > idea as it would encourage the use of closures. But to me it seems > more elegant than some special keyword, especially is it could also > replace the "global" keyword. It doesn't handle things like "x += y" > but I think you could deal with that by just writing "x := x + y". Actually, it could handle += just fine, since that operator has written "rebinding" all over it... I'd be +1 on := (and augmented assignment being rebinding), but the argument against it (if I recall correctly) was that rebinding should be a property of the name, not of the operator. Yet "declaring" a name local is also done trough an operator: a = 1 means a is local (unless it was declared global). It can definitely be argued either way. Btw, PJE's "crazy" idea (.name, to rebind an outer name) was proposed before, but Guido wanted to reserve .name for a (Pascal-like) 'with' statement. Hmm, http://mail.python.org/pipermail/python-dev/2004-March/043545.html confirms that, although it wasn't in response to a rebinding syntax. So maybe it wasn't proposed before after all... 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] PEP for Better Control of Nested Lexical Scopes
Mark Russell wrote: > On 21 Feb 2006, at 19:25, Jeremy Hylton wrote: > >>If I recall the discussion correctly, Guido said he was open to a >>version of nested scopes that allowed rebinding. > > > PEP 227 mentions using := as a rebinding operator, but rejects the > idea as it would encourage the use of closures. But to me it seems > more elegant than some special keyword, especially is it could also > replace the "global" keyword. It doesn't handle things like "x += y" > but I think you could deal with that by just writing "x := x + y". By rebinding operator, does that mean it is actually an operator? I.e.: # Required assignment to declare?: chunk = None while chunk := f.read(1000): ... -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.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] defaultdict proposal round three
Raymond Hettinger wrote: >>Yes, I now agree. This means that I'm withdrawing proposal A (new >>method) and championing only B (a subclass that implements >>__getitem__() calling on_missing() and on_missing() defined in that >>subclass as before, calling default_factory unless it's None). I don't >>think this crisis is big enough to need *two* solutions, and this >>example shows B's superiority over A. > > > FWIW, I'm happy with the proposal and think it is a nice addition to Py2.5. I agree. I would have preferred if dict itself was modified, but after ruling out changes to dict.__getitem__, d[k]+=1 is too important to not support it. 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
[Python-Dev] Two patches
Hi, I have two patches lying around here, please comment: * I think I've submitted this one to the tracker, but can't remember: It's for PySequence_SetItem and makes something like this possible: tup = ([], ) tup[0] += [1] I can upload it once more to allow review. * One patch for staticmethod and classmethod, which currently silently accept keyword arguments and throw them away. The patch adds error messages. Georg ___ 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] buildbot vs. Windows
Tim Peters wrote: > Speaking of which, a number of test failures over the past few weeks > were provoked here only under -r (run tests in random order) or under > a debug build, and didn't look like those were specific to Windows. > Adding -r to the buildbot test recipe is a decent idea. Getting > _some_ debug-build test runs would also be good (or do we do that > already?). So what is your recipe: Add -r to all buildbots? Only to those which have an 'a' in their name? Only to every third build? Duplicating the number of builders? Same question for --with-pydebug. Combining this with -r would multiply the number of builders by 4 already. I'm not keen on deciding this for myself. Somebody else please decide for me. 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] buildbot vs. Windows
Neal Norwitz wrote: >>How many of those do you see when you ignore the warnings you get >>while building the Carbon extensions? Those extensions wrap loads of >>deprecated functions, each of which will give a warning. > > > RIght: > http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/138/step-compile/0 > > Most but not all of the warnings are due to Carbon AFAICT. I'd like > to fix those that are important, but it's so far down on the priority > list. :-( Should we build with -Wno-deprecated (or whatever it is spelled) on OSX? In general, "deprecated" warnings are useless for Python. We *know* we are providing wrappers around many deprecated functions. We will (nearly automatically) discontinue wrapping the functions when they get removed. 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] buildbot vs. Windows
[EMAIL PROTECTED] wrote: > Ronald> How many of those do you see when you ignore the warnings you > Ronald> get while building the Carbon extensions? > > skip> I see a bunch related to Py_ssize_t. Those have nothing to do > skip> with Carbon. I don't see them on the gentoo build, so I assume > skip> they just haven't been tackled yet. > > Let me rephrase that. I assume the people digging through Py_ssize_t issues > have been looking at compilation warnings for platforms other than Mac OSX. In the buildbot log, I see only a single one of these, and only in an OSX-specific module. So no - "we" don't look into fixing them, as they don't occur on Linux at all (as _Qdmodule isn't built on Linux). 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] buildbot vs. Windows
[EMAIL PROTECTED] wrote: > Neal> IMO compiler warnings should generate emails from buildbot. > > It doesn't generate emails for any other condition. I think it should just > turn the compilation section yellow. It would be easy to run the builds with -Werror, making warnings let the compilation fail, which in turn is flagged red. 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] buildbot vs. Windows
Terry Reedy wrote: > "Neal Norwitz" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>There's nothing to prevent buildbot from making debug builds, though >>that is not currently done. > > > Now that there are separate report pages for 2.4 and 2.5, you could add > pages for debug builds, perhaps with a lower frequency (once a day?), > without cluttering up the main two pages. Not soon, unless somebody has a complete recipe how to change the master config. 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] buildbot vs. Windows
Martin> So what is your recipe: Add -r to all buildbots? Only to those Martin> which have an 'a' in their name? Only to every third build? Martin> Duplicating the number of builders? Martin> Same question for --with-pydebug. Combining this with -r would Martin> multiply the number of builders by 4 already. Martin> I'm not keen on deciding this for myself. Somebody else please Martin> decide for me. Now that you've broken the buildbot page into two (trunk and 2.4) I assume breaking it down even further wouldn't be a major undertaking. If we can recruit a suitable number of boxes I see no particular reason you can't support a 2x, 4x, 8x or more increase in the number of buildbot slaves. 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] readline compilarion fails on OSX
Guido van Rossum wrote: > Thanks! That worked. > > But shouldn't we try to fix setup.py to detect this situation instead > of making loud clattering noises? One of my concerns with the distutils build process is that it takes failures lightly. Unlike make, it won't stop when an error occurs, but instead go on with the next module. Then, when you retry make, it will retry building the module again, which will again fail. Also happens with the curses module on Solaris. buildbot's detection of build failures is restricted to the exit status of the build process. The build either succeeds or fails. 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 for Better Control of Nested Lexical Scopes
On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> The question which still remains in my mind, which I previously asked,
> is whether the use cases are compelling enough to warrant the feature
> addition.
I don't know whether I support the proposal or not, but in reading
Mark Russel's email, I realized that I just recently ran into a use
case:
--
# group tokens into chunks by their chunk labels
token_groups = []
curr_suffix = ''
curr_tokens = []
for token in document.IterAnnotations('token', percent=80):
label = token[attr_name]
# determine the prefix and suffix of the label
prefix, suffix = label[0], label[2:]
# B labels start a new chunk
if prefix == 'B':
curr_suffix = suffix
curr_tokens = [token]
token_groups.append((curr_suffix, curr_tokens))
# I labels continue the previous chunk
elif prefix == 'I':
if curr_suffix == suffix:
curr_tokens.append(token)
# error: change in suffix - this should be a B label
else:
# log the error
message = '%r followed by %r'
last_label = curr_tokens[-1][attr_name]
self._logger.info(message % (last_label, label))
# start a new chunk
curr_suffix = suffix
curr_tokens = [token]
token_groups.append((curr_suffix, curr_tokens))
# O labels end any previous chunks
elif prefix == 'O':
curr_suffix = suffix
curr_tokens = [token]
--
You can see that the code::
curr_suffix = suffix
curr_tokens = [token]
token_groups.append((curr_suffix, curr_tokens))
is repeated in two places. I would have liked to factor this out into
a function, but since the code requires rebinding curr_suffix and
curr_tokens, I can't. I'm not sure I care that much -- it's only
three lines of code and only duplicated once -- but using something
like ``curr_suffix :=`` or Phillip J. Eby's suggestion of
``.curr_suffix =`` would allow this code to be factored out into a
function.
STeVe
--
Grammar am for people who can't think for myself.
--- Bucky Katt, Get Fuzzy
___
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] Two patches
Georg Brandl wrote: > * I think I've submitted this one to the tracker, but can't remember: > It's for PySequence_SetItem and makes something like this possible: > > tup = ([], ) > tup[0] += [1] That definitely needs fixing: py> tup = ([], ) py> tup[0] += [1] Traceback (most recent call last): File "", line 1, in ? TypeError: object doesn't support item assignment py> tup ([1],) Errors should never pass silently, but success shouldn't cause an error message, either. > * One patch for staticmethod and classmethod, which currently silently > accept keyword arguments and throw them away. The patch adds error > messages. Sounds good as well. 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] buildbot vs. Windows
[EMAIL PROTECTED] wrote: > Now that you've broken the buildbot page into two (trunk and 2.4) I assume > breaking it down even further wouldn't be a major undertaking. If we can > recruit a suitable number of boxes I see no particular reason you can't > support a 2x, 4x, 8x or more increase in the number of buildbot slaves. Let me explain the procedure for breaking it down, then: - there are builder objects in buildbot, each displayed as a single lane. - each builder now gets a "category" attribute; currently, the categories are "trunk" and "2.4". - for each page, there is an instance of the Waterfall object, constructed with the list of categories to display. Each Waterfall gets its own port number (currently 9010, 9011, and 9012). - There are reverse proxy rules in Apache's httpd.conf, each page requiring 2 lines (giving currently 6 lines of Apache configuration). So for multiplying this by 8, I would have to create 48 lines of Apache configuration, and use 24 TCP ports. This can be done, but it would take some time to implement. And who is going to look at the 24 pages? 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] defaultdict proposal round three
On Tue, 21 Feb 2006, Guido van Rossum wrote: [...] > If you're only interested in classifying the three specific built-ins > you mention, I'd check for the presense of certain attributes: > hasattr(x, "lower") -> x is a string of some kind; hasattr(x, "sort") > -> x is a list; hasattr(x, "update") -> x is a dict. Also, hasattr(x, > "union") -> x is a set; hasattr(x, "readline") -> x is a file. dict and set instances both have an .update() method. I guess "keys" or "items" is a better choice for testing dict-ness, if using "LBYL" at all. (anybody new to "LBYL" can google for that and EAFP -- latter does not stand for European Assoc. of Fish Pathologists in this context, though ;-) > That's duck typing! >>> hasattr(python, "quack") True John ___ 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] Two patches
Martin v. Löwis wrote: > Georg Brandl wrote: >> * I think I've submitted this one to the tracker, but can't remember: >> It's for PySequence_SetItem and makes something like this possible: >> >> tup = ([], ) >> tup[0] += [1] > > That definitely needs fixing: > > py> tup = ([], ) > py> tup[0] += [1] > Traceback (most recent call last): > File "", line 1, in ? > TypeError: object doesn't support item assignment > py> tup > ([1],) > > Errors should never pass silently, but success shouldn't cause > an error message, either. The patch is now at SF, item #1436226. >> * One patch for staticmethod and classmethod, which currently silently >> accept keyword arguments and throw them away. The patch adds error >> messages. > > Sounds good as well. Checked in to 2.5 branch. Georg ___ 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 for Better Control of Nested Lexical Scopes
"Jeremy Hylton" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > If I recall the discussion correctly, Guido said he was open to a > version of nested scopes that allowed rebinding. Yes. Among other places, he said in http://article.gmane.org/gmane.comp.python.devel/25153/match=nested+scopes ''' Your PEP wonders why I am against allowing assignment to intermediate levels. Here's my answer: all the syntaxes that have been proposed to spell this have problems. So let's not provide a way to spell it. I predict that it won't be a problem. If it becomes a problem, we can add a way to spell it later. '' tjr ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP 332 revival in coordination with pep 349?]]
Greg Ewing wrote: > I don't quite see the point here. Inside a bytes object, > they would be stored 1 byte per byte. Nobody is suggesting > that they would take up more than that just because > a_bytes_object[i] happens to return an int. Speaking of which, I suspect it'll be a lot more common to need integer objects in the full range [0, 255] than it is now. Perhaps we should extend the pre-allocated integer objects to cover the full byte range. Tim Delaney ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP332 revival in coordination with pep 349?]]
> Speaking of which, I suspect it'll be a lot more common to need integer > objects in the full range [0, 255] than it is now. > > Perhaps we should extend the pre-allocated integer objects to cover the > full byte range. +1 ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was: PEP332 revival in coordination with pep 349?]]
Raymond Hettinger wrote: >> Speaking of which, I suspect it'll be a lot more common to need >> integer objects in the full range [0, 255] than it is now. >> >> Perhaps we should extend the pre-allocated integer objects to cover >> the full byte range. > > +1 Want me to raise an SF request? Tim Delaney ___ 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] s/bytes/octet/ [Was:Re: bytes.from_hex() [Was:PEP332 revival in coordination with pep 349?]]
Delaney, Timothy (Tim) wrote: >>> Perhaps we should extend the pre-allocated integer objects to cover >>> the full byte range. >> >> +1 > > Want me to raise an SF request? Done. Item # 1436243. Tim Delaney ___ 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 for Better Control of Nested Lexical Scopes
On 21 Feb 2006, at 21:13, Ian Bicking wrote: > By rebinding operator, does that mean it is actually an operator? > I.e.: > ># Required assignment to declare?: >chunk = None >while chunk := f.read(1000): >... No, I think that "x := y" should be a statement not an expression (i.e. just like "x = y" apart from the treatment of bindings). I'd be inclined to require that the target of := be already bound, if only to prevent people randomly using ":=" in places where it's not required. In a new language I would probably also make it an error to use = to do rebinding (i.e. insist on = for new bindings, and := for rebindings). But that's obviously not reasonable for python. Mark Russell ___ 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] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
At 11:50 PM 2/21/2006 +0100, Morel Xavier wrote: >Phillip J. Eby wrote: >>The '.' would mean "this name, but in the nearest outer scope that >>defines it". Note that this could include the global scope, so the >>'global' keyword could go away in 2.5. And in Python 3.0, the '.' could >>become *required* for use in closures, so that it's not necessary for the >>reader to check a function's outer scope to see whether closure is taking >>place. EIBTI. > >While the idea is interesting, how would this solution behave if the >variable (the name) didn't exist in any outer scope? The compiler should consider it a name in the global scope, and for an assignment the name would be required to have an existing binding, or a NameError would result. (Indicating you are assigning to a global that hasn't been defined.) >Would it create and bind the name in the current scope? No, never. > If yes, why wouldn't this behavior become the default (without > any leading dot), efficiency issues of the lookup? No, it would be because explicit is better than implicit. The whole point of requiring '.' for closures in Python 3.0 would be to keep the person who's reading the code from having to inspect an entire function and its context to figure out which names are referring to variables in outer scopes. That is, it would go against the whole point of my idea, which is to make explicit what variables are part of your closure. ___ 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] buildbot vs. Windows
Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: [...] > > So for multiplying this by 8, I would have to create 48 lines of > Apache configuration, and use 24 TCP ports. This can be done, but > it would take some time to implement. And who is going to look > at the 24 pages? This last point is the most important, I think. Most of the time I look at Twisted's buildbot, it's to see at a glance which, if any, builds are broken. I think this is the #1 use case. Second is getting the details of what broke, and who broke it. So massively multiplying the pages seems counter-productive to me. I suspect there's nearly as much advantage to running randomised tests on just one platform as there is on many, so a good trade-off may be to just add one more builder (to each branch) that does -r on just one platform. I'm assuming most of the issues randomisation exposes aren't platform-dependent. -Andrew. ___ 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 for Better Control of Nested Lexical Scopes
Jeremy Hylton wrote: > The names of naming statements are quite hard to get right, I fear. My vote goes for 'outer'. And if this gets accepted, remove 'global' in 3.0. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] bytes.from_hex()
Josiah Carlson wrote: > It doesn't seem strange to you to need to encode data twice to be able > to have a usable sequence of characters which can be embedded in an > effectively 7-bit email; I'm talking about a 3.0 world where all strings are unicode and the unicode <-> external coding is for the most part done automatically by the I/O objects. So you'd be building up your whole email as a string (aka unicode) which happens to only contain code points in the range 0..127, and then writing it to your socket or whatever. You wouldn't need to do the second encoding step explicitly very often. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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 for Better Control of Nested Lexical Scopes
Georg Brandl wrote: > But why is that better than > > class namespace(object): pass > > def my_func(): > foo = namespace() > (...) Because then it would be extremely difficult for CPython to optimise accesses to foo into local variable lookups. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] defaultdict proposal round three
Alex Martelli wrote: > If we call the type autodict, then having the factory attribute named > autofactory seems to fit. Or just 'factory', since it's the only kind of factory the object is going to have. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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 for Better Control of Nested Lexical Scopes
Jeremy Hylton wrote: > On 2/21/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote: > >>On 2/21/06, Bengt Richter <[EMAIL PROTECTED]> wrote: > >>>But to the topic, it just occurred to me that any outer scopes could be >>>given names >>>(including global namespace, but that would have the name global by default, >>>so >>>global.x would essentially mean what globals()['x'] means now, except it >>>would >>>be a name error if x didn't pre-exist when accessed via >>>namespace_name.name_in_space notation. > > Isn't this suggestion that same as Greg Ewing's? It's not quite the same, because in my scheme the namespace statement creates a new namespace embedded in the scope where it appears, whereas Bengt's one seems to just give a name to the scope itself. I'm not really in favour of either of these -- I'd be just as happy with a simple 'outer' statement. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] defaultdict proposal round three
Fuzzyman wrote: > I've had problems in code that needs to treat strings, lists and > dictionaries differently (assigning values to a container where all > three need different handling) and telling the difference but allowing > duck typing is *problematic*. You need to rethink your design so that you don't have to make that kind of distinction. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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] Unifying trace and profile
There are a number of features I'd like to see happen with Python's tracing and profiling subsystems (but I don't have the C experience to do it myself). I started to write an SF feature-request and then realized it was too much for a single ticket. Maybe a PEP? All of these would be make my latest side project[1] a lot easier. Anyway, here they are (most important and easiest-to-implement first): 1. Allow trace hooks to receive c_call, c_return, and c_exception events (like profile does). 2. Allow profile hooks to receive line events (like trace does). 3. Expose new sys.gettrace() and getprofile() methods, so trace and profile functions that want to play nice can call sys.settrace/setprofile(None) only if they are the current hook. 4. Make "the same move" that sys.exitfunc -> atexit made (from a single function to multiple functions via registration), so multiple tracers/profilers can play nice together. 5. Allow the core to filter on the "event" arg before hook(frame, event, arg) is called. 6. Unify tracing and profiling, which would remove a lot of redundant code in ceval and sysmodule and free up some space in the PyThreadState struct to boot. 7. As if the above isn't enough of a dream, it would be nice to have a bytecode tracer, which didn't bother with the f_lineno logic in maybe_call_line_trace, but just called the hook on every instruction. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] [1] PyConquer, a trace hook to help understand and debug concurrent (threaded) code. http://projects.amor.org/misc/wiki/PyConquer ___ 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] buildbot vs. Windows
[Martin v. Löwis] > So what is your recipe: I don't have one. I personally always use -uall and -r, and then run the tests 8 times, w/ and w/o -O, under debug and release builds, and w/ and w/o deleting .py[co] files first. Because that last one almost never finds problems anymore, perhaps it would be good to stop bothering with it routinely (it really doesn't have potential to find a problem unless someone has been mucking with the marshaling of code objects, right?). > Add -r to all buildbots? Sure. -r adds variety to testing at no cost (the same number of tests run, in the same pamount of time, with or without -r). > Only to those which have an 'a' in their name? Sorry, no idea what that means. > Only to every third build? Duplicating the number of builders? For -r, no. I'd always use -r (and always do anyway). > Same question for --with-pydebug. Combining this with -r would multiply > the number of builders by 4 already. I would much rather see a debug-build run than the current "with and without deleting .py[co] files first" variant. If the latter were dropped and the former were added, and -r were used all the time, the number of recipes wouldn't change. Testing time would increase, by the time to _do_ a debug build, and by the extra time a debug build test run requires. We should test with and without -O too, although that's another that rarely finds a problem. > I'm not keen on deciding this for myself. Somebody else please decide > for me. I don't know how hard it is to teach the system how to do something "not so often", and I expect that's an important unknown since I imagine that vastly increasing test time would discourage people from volunteering buildbot slaves. Since the most fruitful variations (IME) for finding code errors are using -r and running a debug build too, I'd change the current run-all-the-time recipes to: - Stop doing the second "without deleting .py[co]" run. - Do one run with a release build. - Do one run with a debug build. - Use -uall -r for both. If we know how to get something done "occasionally", then about once a week it would be prudent to also: - Try the "with and without deleting .py[co] files first" business. - Try with and without -O, Those last two choices cover 8 distinct modes, when paired with each other and with the "release versus debug build" choice. ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 385 open (-14) / 3067 closed (+25) / 3452 total (+11) Bugs: 864 open (-59) / 5621 closed (+68) / 6485 total ( +9) RFE : 211 open ( +2) / 200 closed ( +2) / 411 total ( +4) New / Reopened Patches __ GNU uses double-dashes not single (2006-02-16) http://python.org/sf/1433148 opened by splitscreen restrict codec lookup to encodings package (2006-02-16) CLOSED http://python.org/sf/1433198 reopened by lemburg restrict codec lookup to encodings package (2006-02-16) CLOSED http://python.org/sf/1433198 opened by Guido van Rossum add on_missing() and default_factory to dict (2006-02-17) http://python.org/sf/1433928 opened by Guido van Rossum CHM file contains proprietary link format (2006-02-18) http://python.org/sf/1434298 opened by Alexander Schremmer Patch to support lots of file descriptors (2006-02-19) http://python.org/sf/1434657 opened by Sven Berkvens-Matthijsse Add copy() method to zlib's compress and decompress objects (2006-02-20) http://python.org/sf/1435422 opened by Chris AtLee PEP 343 with statement (2006-02-21) http://python.org/sf/1435715 opened by mbland Incremental codecs (2006-02-21) http://python.org/sf/1436130 opened by Walter Dörwald fix inplace assignment for immutable sequences (2006-02-21) http://python.org/sf/1436226 opened by Georg Brandl Patches Closed __ GNU uses double-dashes not single (2006-02-16) http://python.org/sf/1433166 deleted by gvanrossum restrict codec lookup to encodings package (2006-02-16) http://python.org/sf/1433198 closed by lemburg restrict codec lookup to encodings package (2006-02-16) http://python.org/sf/1433198 closed by lemburg use computed goto's in ceval loop (2006-01-18) http://python.org/sf/1408710 closed by loewis have SimpleHTTPServer return last-modified headers (2006-01-28) http://python.org/sf/1417555 closed by birkenfeld Feed style codec API (2005-01-12) http://python.org/sf/1101097 closed by lemburg chunk.py can't handle >2GB chunks (2005-12-05) http://python.org/sf/1373643 closed by birkenfeld Fix of bug 1366000 (2005-11-30) http://python.org/sf/1370147 closed by birkenfeld Optional second argument for startfile (2005-12-29) http://python.org/sf/1393157 closed by birkenfeld Clairify docs on reference stealing (2006-01-26) http://python.org/sf/1415507 closed by birkenfeld urllib proxy_bypass broken (2006-02-07) http://python.org/sf/1426648 closed by birkenfeld Speed up EnumKey call (2004-06-22) http://python.org/sf/977553 closed by birkenfeld [PATCH] Bug #1351707 (2005-11-10) http://python.org/sf/1352711 closed by birkenfeld fileinput patch for bug #1336582 (2005-10-25) http://python.org/sf/1337756 closed by birkenfeld Fix for int(string, base) wrong answers (2005-10-22) http://python.org/sf/1334979 closed by birkenfeld [PATCH] 100x optimization for ngettext (2005-11-06) http://python.org/sf/1349274 closed by birkenfeld commands.getstatusoutput() (2005-11-02) http://python.org/sf/1346211 closed by birkenfeld two fileinput enhancements (fileno, openhook) (2005-06-05) http://python.org/sf/1215184 closed by birkenfeld mode argument for fileinput class (2005-05-31) http://python.org/sf/1212287 closed by birkenfeld do not add directory of sys.argv[0] into sys.path (2004-05-02) http://python.org/sf/946373 closed by gbrandl prefix and exec_prefix as root dir bug (2004-04-08) http://python.org/sf/931938 closed by gbrandl New / Reopened Bugs ___ optparse docs double-dash confusion (2006-02-16) http://python.org/sf/1432838 opened by John Veness Logging hangs thread after detaching a StreamHandler's termi (2006-02-13) CLOSED http://python.org/sf/1431253 reopened by yangzhang os.path.expandvars sometimes doesn't expand $HOSTNAME (2006-02-17) CLOSED http://python.org/sf/1433667 opened by Doug Fort normalize function in minidom unlinks empty child nodes (2006-02-17) http://python.org/sf/1433694 opened by RomanKliotzkin string parameter to ioctl not null terminated, includes fix (2006-02-17) http://python.org/sf/1433877 opened by Quentin Barnes pointer aliasing causes core dump, with workaround (2006-02-17) http://python.org/sf/1433886 opened by Quentin Barnes Python crash on __init__/__getattr__/__setattr__ interaction (2004-04-26) CLOSED http://python.org/sf/942706 reopened by hhas Crash when decoding UTF8 (2006-02-20) CLOSED http://python.org/sf/1435487 opened by Viktor Ferenczi CGIHTTPServer doesn't handle path names with embeded space (2006-02-21) http://python.org/sf/1436206 opened by Richard Coupland Bugs Closed ___ Logging hangs thread af
[Python-Dev] Fixing copy.py to allow copying functions
While playing around with the defaultdict patch, adding __reduce__ to
make defaultdict objects properly copyable through the copy module, I
noticed that copy.py doesn't support copying function objects. This
seems an oversight, since the (closely related) pickle module *does*
support copying functions. The semantics of pickling a function is
that it just stores the module and function name in the pickle; that
is, if you unpickle it in the same process it'll just return a
reference to the same function object. This would translate into
"atomic" semantics for copying functions: the "copy" is just the
original, for shallow as well as deep copies. It's a simple patch:
--- Lib/copy.py (revision 42537)
+++ Lib/copy.py (working copy)
@@ -101,7 +101,8 @@
return x
for t in (type(None), int, long, float, bool, str, tuple,
frozenset, type, xrange, types.ClassType,
- types.BuiltinFunctionType):
+ types.BuiltinFunctionType,
+ types.FunctionType):
d[t] = _copy_immutable
for name in ("ComplexType", "UnicodeType", "CodeType"):
t = getattr(types, name, None)
@@ -217,6 +218,7 @@
d[xrange] = _deepcopy_atomic
d[types.ClassType] = _deepcopy_atomic
d[types.BuiltinFunctionType] = _deepcopy_atomic
+d[types.FunctionType] = _deepcopy_atomic
def _deepcopy_list(x, memo):
y = []
Any objections? Given that these are picklable, I can't imagine there
are any but I thought I'd ask anyway.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] buildbot vs. Windows
>> Let me rephrase that. I assume the people digging through Py_ssize_t >> issues have been looking at compilation warnings for platforms other >> than Mac OSX. Martin> In the buildbot log, I see only a single one of these, and only Martin> in an OSX-specific module. So no - "we" don't look into fixing Martin> them, as they don't occur on Linux at all (as _Qdmodule isn't Martin> built on Linux). Sure looks like core to me: Objects/bufferobject.c: In function `buffer_repr': Objects/bufferobject.c:250: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/bufferobject.c:258: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/bufferobject.c:258: warning: signed size_t format, Py_ssize_t arg (arg 5) ... Objects/funcobject.c: In function `func_set_code': Objects/funcobject.c:254: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/funcobject.c:254: warning: signed size_t format, Py_ssize_t arg (arg 5) Objects/funcobject.c: In function `func_new': Objects/funcobject.c:406: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/funcobject.c:406: warning: signed size_t format, Py_ssize_t arg (arg 5) ... Objects/listobject.c: In function `list_ass_subscript': Objects/listobject.c:2604: warning: signed size_t format, Py_ssize_t arg (arg 3) Objects/listobject.c:2604: warning: signed size_t format, Py_ssize_t arg (arg 4) ... Objects/dictobject.c: In function `PyDict_MergeFromSeq2': Objects/dictobject.c:1152: warning: signed size_t format, Py_ssize_t arg (arg 4) ... Objects/methodobject.c: In function `PyCFunction_Call': Objects/methodobject.c:85: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/methodobject.c:96: warning: signed size_t format, Py_ssize_t arg (arg 4) ... Objects/structseq.c: In function `structseq_new': Objects/structseq.c:129: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/structseq.c:129: warning: signed size_t format, Py_ssize_t arg (arg 5) Objects/structseq.c:137: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/structseq.c:137: warning: signed size_t format, Py_ssize_t arg (arg 5) Objects/structseq.c:146: warning: signed size_t format, Py_ssize_t arg (arg 4) Objects/structseq.c:146: warning: signed size_t format, Py_ssize_t arg (arg 5) ... Objects/typeobject.c: In function `check_num_args': Objects/typeobject.c:3378: warning: signed size_t format, Py_ssize_t arg (arg 4) ... Objects/unicodeobject.c: In function `unicode_decode_call_errorhandler': Objects/unicodeobject.c:794: warning: signed size_t format, Py_ssize_t arg (arg 3) Objects/unicodeobject.c: In function `unicode_encode_call_errorhandler': Objects/unicodeobject.c:2475: warning: signed size_t format, int arg (arg 3) Objects/unicodeobject.c: In function `unicode_translate_call_errorhandler': Objects/unicodeobject.c:3374: warning: signed size_t format, int arg (arg 3) ... This from the build on g5 osx.3 trunk from 22:54 today (21 Feb). 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] PEP for Better Control of Nested Lexical Scopes
"Steven Bethard" <[EMAIL PROTECTED]> wrote: > > On 2/21/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > The question which still remains in my mind, which I previously asked, > > is whether the use cases are compelling enough to warrant the feature > > addition. > > I don't know whether I support the proposal or not, but in reading > Mark Russel's email, I realized that I just recently ran into a use > case: [snip example where 3 lines are duplicated twice, and a 2 line subset are duplicated in a third location] > using something > like ``curr_suffix :=`` or Phillip J. Eby's suggestion of > ``.curr_suffix =`` would allow this code to be factored out into a > function. In this particular example, there is no net reduction in line use. The execution speed of your algorithm would be reduced due to function calling overhead. There may be a minor clarification improvement, but arguably no better than the Richie Hindle's functional goto implementation for Python 2.3 and later. - Josiah ___ 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] buildbot vs. Windows
Martin> So for multiplying this by 8, I would have to create 48 lines of Martin> Apache configuration, and use 24 TCP ports. This can be done, Martin> but it would take some time to implement. I'm not too worried about that because it's a one-time cost. I'd be willing to help out. Just shoot me the httpd config file and other necessary bits and I'll return you the modified stuff. Martin> And who is going to look at the 24 pages? This is, of course, the bigger problem since it's ongoing. If we solicit buildbot slaves we should solicit a pair of eyeballs for each slave as well. That doesn't need to be the owner of the box, but the owner is the likely first candidate to trick^H^H^H^H^Hask. 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] defaultdict proposal round three
> Alex Martelli wrote: > >> If we call the type autodict, then having the factory attribute named >> autofactory seems to fit. > > Or just 'factory', since it's the only kind of factory > the object is going to have. Gack, no. You guys are drifting towards complete ambiguity. You might as well call it "thingie_that_doth_return_an_object". The word "factory" by itself says nothing about lookups and default values. Like "autodict" could mean anything. Keep in mind that we may well end-up having this side-by-side with collections.ordered_dict. The word "auto" tells you nothing about how this is different from a regular dict or ordered dictionary. It's meaningless. Please, stick with defaultdictionary and default_factory. While not perfectly descriptive, they are suggest just enough to jog the memory and make the code readable. Try to resist generalizing the name into nothingness. Raymond ___ 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] Path PEP: some comments (equality)
Hi, It seems that the Path module as currently defined leaves equality testing up to the underlying string comparison. My guess is that this is fine for Unix (maybe not even) but it is a bit lacking for Windows. Should the path class implement an __eq__ method that might do some of the following things: - Get the absolute path of both self and the other path - normcase both - now see if they are equal This would make working with paths much easier for keys of a dictionary on windows. (I frequently use a case insensitive string class for paths if I need them to be keys of a dict.) My first email to python-dev :-) 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
[Python-Dev] calendar.timegm
Hello. Historical question ;) Anyone can explain why function timegm is placed into module calendar, not to module time, where it would be near with similar function mktime? ___ 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] calendar.timegm
Sergey> Historical question ;) Sergey> Anyone can explain why function timegm is placed into module Sergey> calendar, not to module time, where it would be near with Sergey> similar function mktime? Historical accident. ;-) 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] buildbot vs. Windows
On 2/21/06, Tim Peters <[EMAIL PROTECTED]> wrote: > > Since the most fruitful variations (IME) for finding code errors are > using -r and running a debug build too, I'd change the current > run-all-the-time recipes to: > > - Stop doing the second "without deleting .py[co]" run. > - Do one run with a release build. > - Do one run with a debug build. > - Use -uall -r for both. I agree with this, but don't know a clean way to do 2 builds. I modified buildbot to: - Stop doing the second "without deleting .py[co]" run. - Do one run with a debug build. - Use -uall -r for both. Buildbot does *not* also do a release build. That's the only difference between your request above. I agree that it would be desirable, but I think the debug build is more important than the release build right now. We don't have to make this perfect right now. We can talk about this at PyCon and resolve the remaining issues. One thing that would be nice is to have the master.cfg checked in somewhere so we can track changes. n ___ 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
