[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
Indeed, normative annex https://www.unicode.org/reports/tr31/tr31-35.html
section 5 says: "if the programming language has case-sensitive
identifiers, then Normalization Form C is appropriate" (vs NFKC for a
language with case-insensitive identifiers) so to follow the standard we
should have used NFC rather than NFKC. Not sure if it's too late to fix
this "oops" in future Python versions.
Alex
On Sun, Nov 14, 2021 at 9:17 AM Christopher Barker
wrote:
> On Sat, Nov 13, 2021 at 2:03 PM wrote:
>
>> def 횑퓮햑풍표():
>>
>> try:
>>
>> 픥e헅핝횘︴ = "Hello"
>>
>> 함픬r퓵ᵈ﹎ = "World"
>>
>> ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!")
>>
>> except 퓣핪ᵖｅ햤헿ᵣ햔횛 as ⅇ헑c:
>>
>> 풑rℹₙₜ("failed: {}".핗헼ʳᵐªｔ(ᵉ퐱퓬))
>>
>
> Wow. Just Wow.
>
> So why does Python apply NFKC normalization to variable names?? I can't
> for the life of me figure out why that would be helpful at all.
>
> The string methods, sure, but names?
>
> And, in fact, the normalization is not used for string comparisons or
> hashes as far as I can tell.
>
> In [36]: weird
> Out[36]: 'ᵖ햗퐢혯퓽'
>
> In [37]: normal
> Out[37]: 'print'
>
> In [38]: eval(weird + "('yup, that worked')")
> yup, that worked
>
> In [39]: weird == normal
> Out[39]: False
>
> In [40]: weird[0] in normal
> Out[40]: False
>
> This seems very odd (and dangerous) to me.
>
> Is there a good reason? and is it too late to change it?
>
> -CHB
>
>
>
>
>
>
>
>
>
>>
>>
>> if _︴ⁿ퓪푚핖__ == "__main__":
>>
>> 풉eℓˡ허()
>>
>>
>>
>>
>>
>> # snippet from unittest/util.py
>>
>> _퓟Ⅼ햠홲험ℋ풪Lᴰ푬핽﹏핷피헡 = 12
>>
>> def _픰ʰ퓸ʳ핥홚푛(픰, p푟픢fi햝핝횎푛, ｓᵤ푓헳헂푥헹ₑ횗):
>>
>> ˢ헸ｉ헽 = 퐥ｅ혯(햘) - ｐr횎햋퐢x헅ᵉ퓷 - 풔홪ffｉ혅헹홚ₙ
>>
>> if sｋi혱 > _퐏헟햠혊홴H핺Ｌ핯홀혙﹏L픈풩:
>>
>> 혴 = '%s[%d chars]%s' % (홨[:혱퐫핖푓핚ｘℓ풆핟], ₛ횔풊p, 퓼[퓁풆햓
>> (횜) - 홨횞풇fix홡ᵉ혯:])
>>
>> return ₛ
>>
>>
>>
>>
>>
>> You should able to paste these into your local UTF-8-aware editor or IDE
>> and execute them as-is.
>>
>>
>>
>> (If this doesn’t come through, you can also see this as a GitHub gist at
>> Hello,
>> World rendered in a variety of Unicode characters (github.com)
>> . I have
>> a second gist containing the transformer, but it is still a private gist
>> atm.)
>>
>>
>>
>>
>>
>> Some other discoveries:
>>
>> “·” (ASCII 183) is a valid identifier body character, making “_···” a
>> valid Python identifier. This could actually be another security attack
>> point, in which “s·join(‘x’)” could be easily misread as “s.join(‘x’)”, but
>> would actually be a call to potentially malicious method “s·join”.
>>
>> “_” seems to be a special case for normalization. Only the ASCII “_”
>> character is valid as a leading identifier character; the Unicode
>> characters that normalize to “_” (any of the characters in “︳︴﹍﹎﹏＿”) can
>> only be used as identifier body characters. “︳” especially could be
>> misread as “|” followed by a space, when it actually normalizes to “_”.
>>
>>
>>
>>
>>
>> Potential beneficial uses:
>>
>> I am considering taking my transformer code and experimenting with an
>> orthogonal approach to syntax highlighting, using Unicode groups instead of
>> colors. Module names using characters from one group, builtins from
>> another, program variables from another, maybe distinguish local from
>> global variables. Colorizing has always been an obvious syntax highlight
>> feature, but is an accessibility issue for those with difficulty
>> distinguishing colors. Unlike the “ransom note” code above, code
>> highlighted in this way might even be quite pleasing to the eye.
>>
>>
>>
>>
>>
>> -- Paul McGuire
>>
>>
>>
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/GBLXJ2ZTIMLBD2MJQ4VDNUKFFTPPIIMO/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/U3DJOQKMREWY35SHCRSD6V6FQA2T3SW7/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Retrieve an arbitrary element from a set without removing it
Next(s) would seem good... Alex Sent from my iPhone On Oct 24, 2009, at 6:47 PM, John Arbash Meinel john.mei...@canonical.com wrote: Adam Olsen wrote: On Fri, Oct 23, 2009 at 11:04, Vitor Bosshard algor...@gmail.com wrote: I see this as being useful for frozensets as well, where you can't get an arbitrary element easily due to the obvious lack of .pop(). I ran into this recently, when I had a frozenset that I knew had 1 element (it was the difference between 2 other sets), but couldn't get to that element easily (get the pun?) item, = set_of_one Interesting. It depends a bit on the speed of tuple unpacking, but presumably that is quite fast. On my system it is pretty darn good: 0.101us for x in s: break 0.112us x, = s 0.122us for x in s: pass So not quite as good as the for loop, but quite close. John =:- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] (try-except) conditional expression similar to (if-else) conditional (PEP 308)
2009/8/7 Kristján Valur Jónsson krist...@ccpgames.com: Unless I am very much mistaken, this is the approach Ruby takes. Everything is an expression. For example, the value of a block is the value of The last expression in the block. I've never understood the need to have a distinction betwen statements and expressions, not when expressions can have side effects. It's like that differentce between procedures and functions in pascal that only serves to confuse If you're interested in understanding it better, research Query-Command Separation (QCS), e.g. starting at http://en.wikipedia.org/wiki/Command-query_separation and links therefrom. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-with statement
FWIW, I prefer Fredrik's wish too. Alex On Sat, May 2, 2009 at 12:26 PM, Fredrik Johansson fredrik.johans...@gmail.com wrote: On Sat, May 2, 2009 at 9:01 PM, Georg Brandl g.bra...@gmx.net wrote: Hi, this is just a short notice that Mattias Brändström and I have finished a patch to implement the previously discussed and mostly warmly welcomed extension to with's syntax, allowing with A() as a, B() as b: to be written instead of with A() as a: with B() as b: This syntax was chosen (over with A(), B() as a, b:) because it has more syntactical similarity to the written-out version. Also, our current uses of as all have only one expression on the right. The patch implements it as a simple AST transformation, which guarantees semantic equivalence. It is at http://codereview.appspot.com/53094. If there is no strong opposition, I will commit it and port it to py3k before 3.1 enters beta stage. cheers, Georg I was hoping for the other syntax in order to be able to create a nested context in advance as a simple tuple: with A, B: pass context = A, B with context: pass (I.e. a tuple, or perhaps any iterable, would be a valid context manager.) With the syntax in the patch, I will still have to implement a custom nesting context manager to do this, which sort of defeats the purpose. Fredrik ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python3 and arm-linux
On Thu, Apr 23, 2009 at 11:21 AM, cyberGn0m cy6erg...@gmail.com wrote: Somebody knowns, is python3 works on arm-linux. Is it possible to build it? Where to find related discussions? Maybe some special patches already available? Should i try to get sources from svn or get known version snapshot? I haven't tried, but there's an interesting distro at http://www.vanille-media.de/site/index.php/projects/python-for-arm-linux/ -- I don't know if other such distros have better-updated Python versions (eg. current 2.6.* vs that one's 2.4.*) but that one includes a lot of very useful add-ons. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible py3k io wierdness
On Sun, Apr 5, 2009 at 3:54 PM, Nick Coghlan ncogh...@gmail.com wrote: Antoine Pitrou wrote: James Y Knight foom at fuhm.net writes: It seems that a separate method _internal_close should've been defined to do the actual closing of the file, and the close() method should've been defined on the base class as self.flush(); self._internal_close() and never overridden. I'm completely open to changes as long as there is a reasonable consensus around them. Your proposal looks sane, although the fact that a semi-private method (starting with an underscore) is designed to be overriden in some classes is a bit annoying. Note that we already do that in a couple of places where it makes sense - in those cases the underscore is there to tell *clients* of the class don't call this directly, but it is still explicitly documented as part of the subclassing API. (the only example I can find at the moment is in asynchat, but I thought there were a couple of more common ones than that - hopefully I'll think of them later) Queue.Queue in 2.* (and queue.Queue in 3.*) is like that too -- the single leading underscore meaning protected (I'm here for subclasses to override me, only in C++ parlance) and a great way to denote hook methods in a Template Method design pattern instance. Base class deals with all locking issues in e.g. 'get' (the method a client calls), subclass can override _get and not worry about threading (it will be called by parent class's get with proper locks held and locks will be properly released c afterwards). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] And the winner is...
On Tue, Mar 31, 2009 at 5:42 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen J. Turnbull wrote: I also just wrote a long post about the comparison of bzr to hg responding to a comment on baz...@canonical.com. I won't recap it here but it might be of interest. Thank you very much for your writeups on that thread: both in tone and in content I found them extremely helpful. I'd like to read that thread for my edification -- might there be a URL for it perhaps...? Thanks, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] And the winner is...
On Tue, Mar 31, 2009 at 5:42 PM, Tres Seaver tsea...@palladion.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephen J. Turnbull wrote: I also just wrote a long post about the comparison of bzr to hg responding to a comment on baz...@canonical.com. I won't recap it here but it might be of interest. Thank you very much for your writeups on that thread: both in tone and in content I found them extremely helpful. I'd like to read that thread for my edification -- might there be a URL for it perhaps...? Thanks, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] And the winner is...
On Tue, Mar 31, 2009 at 6:33 PM, Alexandre Vassalotti alexan...@peadrop.com wrote: ... html https://lists.ubuntu.com/archives/bazaar/2009q1/055850.html https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html Perfect, thanks! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] And the winner is...
On Tue, Mar 31, 2009 at 6:33 PM, Alexandre Vassalotti alexan...@peadrop.com wrote: ... html https://lists.ubuntu.com/archives/bazaar/2009q1/055850.html https://lists.ubuntu.com/archives/bazaar/2009q1/055872.html Perfect, thanks! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS X Installer for 3.0.1 and supported versions
On Sat, Feb 14, 2009 at 3:22 AM, Ned Deily n...@acm.org wrote: ... have done complete and thorough testing. (In particular, I have no access to a G5 for 64-bit PPC testing.) I have a PowerMac G5 at home and I'll be glad to run tests if it helps. (It runs 10.5: family pack licenses are cheap, so I've always routinely upgraded all my home Macs to recent OSX releases). (I'm not home during the weekend though). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... Alex On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński [EMAIL PROTECTED] wrote: Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
On Sun, Nov 30, 2008 at 2:02 PM, Filip Gruszczyński [EMAIL PROTECTED] wrote: Yeah, any time someone implements their own attribute lookup process for a class (be it via __getattr__, __getattribute__ or the C equivalents), it is up to the reimplementation to appropriately format their error message if they raise AttributeError directly. I guess, this means that I have to go to Phil Thompson at Riverbank and try to convince him to change the message. Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __import__ problems
On Fri, Nov 28, 2008 at 9:47 AM, Steven D'Aprano [EMAIL PROTECTED] wrote: On Sat, 29 Nov 2008 03:30:49 am Christian Heimes wrote: ... May I point you to the two leading underscores? The name '__import__' clearly suggests that the function is part of Python's internals. By definition all attributes of the form __*__ are not meant to be used directly. What about __doc__, __name__ and __slots__, to mention just a few? Excellent examples of not meant to be used directly. __slots__, like most other special names (though not all) is meant to be *bound* directly when you need to (which for __slots__ is much more rarely than for many other special names, mostly those of special methods that often need to be overridden); but none of these are meant to be *used* in normal cases -- introspection should normally be done via provided tools such as the help built-in and standard library modules such as pydoc and inspect. It's pretty rare to have to write your own introspection framework, and the dunder-names are internal machinery exposed for those rare use cases. I believe that __import__() is the recommended way to import a module known only at runtime. The docs also don't seem to agree with your assertion that __import__ is not to be touched. On the contrary: The function is invoked by the import statement. It mainly exists so that you can replace it with another function that has a compatible interface... http://docs.python.org/library/functions.html Yes, that documentation predates the current generation of import hooks which almost remove the need for such trickery. Far from saying Do Not Touch, the docs say Please, go ahead and replace __import__ if needed. If the OP wants import x.y.z to load module z instead of x, it seems to me that is exactly the problem __import__ is designed to allow him to do. import x.y.z, the import statement, has well defined semantics relying on __import__'s interface -- it does load z as well as, inevitably, its parent y and grandparent x. If __import__ was replaced with a version with NON compatible interface, import x.y.z would break. Any suggestion to change the arguments of __import__() are futile. It's not going to happen unless the feature is required by Python's internal import system. That may very well be true, but I don't know why you're dumping on me. It wasn't my suggestion to change __import__. I merely said I could see some advantages to it. I spent most of my post telling the OP why I thought his arguments were wrong! And now we're telling you why we think your arguments are also wrong -- what else do you expect from python-dev after all? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] My patches
On Sun, Nov 2, 2008 at 5:42 AM, Barry Warsaw [EMAIL PROTECTED] wrote: ... A dvcs means that people can publish their branches in a wide variety of ways. Trusted developers can push their branches to code.python.org. Non-core developers can use one of the free public dvcs branch hosting service. Industrious users can self-publish their branches. Anyone with BTW, if we go with hg, I recommend bitbucket.org as a free public (hg) hosting service of choice -- Jesper (the owner and developer of the site) is friendly and solicitous in his maintenance, the whole site is quite OS-friendly in general (free professional-level accounts and support for open-source projects which choose to host there) and Python-friendly in particular (I gather the site's coded in Python), and my experience there has been nothing short of excellent. All it's missing is a simple code review tool like code.google.com's or Rietveld, but Jesper's promised me he would integrate something to that effect... Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] json decoder speedups, any time left for 2.6?
Meanwhile, can you please release (wherever you normally release things;-) the pure-Python version as well? I'd like to play around with it in Google App Engine opensource sandboxes (e.g., cfr. gae-json-rest -- I'll be delighted to add you to that project if you want of course;-) and that requires Python 2.5 and only pure-Python add-ons... thanks! Alex On Wed, Sep 24, 2008 at 8:08 AM, Bob Ippolito [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 6:14 AM, Barry Warsaw [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 24, 2008, at 5:47 AM, Nick Coghlan wrote: Bob Ippolito wrote: How much time do I have left to get this into Python 2.6? Zero I'm afraid - with rc1 out, it's release blocker bugs only. Anything which can be deferred to the 2.6.1 release without causing any major harm is definitely out - and while a 2x speedup is very nice, it isn't something to be squeezing in post-rc1. Still, that should make for a nice incremental improvement when 2.6.1 rolls around. I concur. Ok, no problem. The speedup is about 3x now on the trunk ;) I think that further optimization will require some more C hacking, but 2.6.1 should give me plenty of time to get around to some of that. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FreeBSD 7 amd64 and large memory tests
Unbelievable as this may seem, this crazy over-committing malloc behavior is by now a classic -- I first fought against it in 1990, when IBM released AIX 3 for its then-new RS/6000 line of workstations; in a later minor release they did provide a way to optionally switch this off, but, like on Linux, it's a system-wide switch, NOT per-process:-(. I concur with http://www.win.tue.nl/~aeb/linux/lk/lk-9.html (the best explanation I know of the subject, and recommended reading) which, on this subject, says Linux on the other hand is seriously broken. (just like AIX 3 was). Sad to learn that BSD is now also broken in the same way:-(. Alex On Wed, Sep 17, 2008 at 8:00 AM, James Y Knight [EMAIL PROTECTED] wrote: On Sep 17, 2008, at 10:53 AM, Andrew MacIntyre wrote: Martin v. Löwis wrote: I haven't yet tried posting a query to a FreeBSD list, as it could simply be a bug on amd64, but I was wondering whether there was anything (other than deactivating tests and documenting use of ulimit -v on this platform) that could be done to work around this behaviour. I think it should be possible to debug this (for people with access to such a system, and appropriate skills). I find it hard to believe that a large malloc will simply crash the process, rather than returning NULL. More likely, there is a NULL returned somewhere, and Python (or libc) fails to check for it. A simple C program doing a repetitive malloc(), much as pymalloc would with continuous demand, does indeed not see any NULL from malloc() when swap is exhausted but the process gets KILLed (the allocated memory does have to be written to to force the situation...) I'll take this up with FreeBSD folk, but I'm open to ideas as to how best to deal with the problem in the context of the test suite pending resolution by FreeBSD. Linux does the same thing, unless the user has explicitly configured that behavior off. Search the web for linux overcommit. It's controlled by the vm.overcommit_memory sysctl. Although linux's default is some heuristic that might make Python's test case work right in most cases, depending on malloc returning NULL is not something you can actually depend on. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Things to Know About Super
On Tue, Aug 26, 2008 at 10:24 PM, Michele Simionato [EMAIL PROTECTED] wrote: ... .. code-block:: python def include_mixin(mixin, cls): # could be extended to use more mixins # traits as in Squeak take the precedence over the base class dic = vars(mixin).copy() # could be extended to walk the ancestors return type(mixin.__name__ + cls.__name__, (cls,), dic) I don't see any use of this in your following example so I assume you're introducing it just to be able to say that: In the fictional world there is not need for super since all hierarchies are linear and you can just call the base class; Nevertheless I must be missing something in the following example: FrameworkMeta could have been written as .. code-block:: python class FrameworkMeta2(type): def __new__(mcl, name, bases, dic): print Adding framework features to %s % name return type.__new__(mcl, name, bases, dic) and DebugMetas as .. code-block:: python class DebugMeta2(type): def __new__(mcl, name, bases, dic): print Adding debugging features to %s % name return mcl.__base__.__new__(mcl, name, bases, dic) Notice that DebugMeta2 is performing a sort of cooperative call here (``mcl.__base__.__new__``) but dead simple since there is just one base class. The analogous of FrameworkClass can be defined as class FrameworkClass2(object): ... __metaclass__ = FrameworkMeta2 Adding framework features to FrameworkClass2 and the analogous of DebugFrameworkClass as class DebugFrameworkClass2(FrameworkClass2): ... __metaclass__ = DebugFrameworkMeta2 What's DebugFrameworkMeta2? I assume it's some kind of mix but I don't see it defined anywhere so I'm having to guess. Adding debugging features to DebugFrameworkClass2 Adding framework features to DebugFrameworkClass2 But where does DebugMeta2 get injected or otherwise get into the picture in this example, so that the Adding debugging features print executes? I don't see any code in your example that performs this injection. Maybe you're missing a key bit where you build DebugFrameworkMeta2 by using that example include_mixin you have? I'd like to understand what, in this example, removes the apparent fragility (or, lack of flexibility) where DebugMeta2 specifically uses mcl.__base__ -- IOW, if I have another mixin metaclass just like DebugMeta2 but called (say) RemotableMeta which does a print Adding remoting features and then also calls mcl.__base__.__new__(mcl ... just like DebugMeta2, what gets both of their __new__ methods called in the right order? Maybe you could help me understand this by giving a fully executable Python snippet using __bases__[0] instead of the hypothetical __base__? A;ex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fileobj.read(float): warning or error?
I thought that's what we had __index__ for -- reject arguments that don't SMOOTHLY turn into integers when an integer is actually required! Alex On Mon, Jul 21, 2008 at 10:01 PM, Martin v. Löwis [EMAIL PROTECTED] wrote: Well, the real problem is os.urandom(4.2) which goes to an unlimited loop: while len(bytes) n: bytes += read(_urandomfd, n - len(bytes)) because read(0.2) works as read(0) :-/ I can't quite accept that as a bug in the library. If you give invalid parameters, Python should not crash, but it may start to behave in a nonsensical way. Of course, it would be possible to move the conversion warning one layer up, into os.urandom; if the argument is float, raise a warning, and then truncate. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] assertRaises
On Thu, Jul 17, 2008 at 2:54 AM, Antoine Pitrou [EMAIL PROTECTED] wrote: I said: Let's just make assertRaises return the exception instance, it seems like it feels the need correctly. and I meant fills, not feels, obviously... +1 : enriching the existing method in a way that's perfectly transparent and innocuous to all existing uses _feels_ right, because it's more practical. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r64424 - inpython/trunk:Include/object.h Lib/test/test_sys.pyMisc/NEWSObjects/intobject.c Objects/longobject.cObjects/typeobject.cPython/bltinmodule.c
On Sat, Jun 28, 2008 at 4:46 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: From: Mark Dickinson [EMAIL PROTECTED] There's one other major difference between the C99 notation and the current patch: the C99 notation includes a (hexa)decimal point. The advantages of this include: - the exponent gives a rough idea of the magnitude of the number, and - the exponent doesn't vary with changes to the least significant bits of the float. Is everyone agreed on a tohex/fromhex pair using the C99 notation as recommended in 754R? Dunno about everyone, but I'm +1 on that. Are you thinking of math module functions or as a method and classmethod on floats? I'd prefer math modules functions. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a with statement?
On Wed, Jun 18, 2008 at 9:58 PM, Cesare Di Mauro [EMAIL PROTECTED] wrote: Very very, interesting. Thanks. :) Somebody thinks that Python is unsuitable to implement a DSL: IMO your example prove the contrary. :D As long as you're willing to do the DSL within the strictures of Python syntax, it's OK - not quite as flexible as LISP or Scheme or even Ruby, but better than most;-). I did design and implement DSLs in Python (mostly specialized class trees with suitable metaclasses, decorators c) in many jobs in my recent past, I'll admit -- it never feels as free-flowing as Scheme did back when I used THAT, but, close enough to make my jobs successful!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a with statement?
+1 on updating the FAQ. Maybe we could even have it notice that a read-only version of the desired semantic for 'with' is easily hacked with the *current* semantic of 'with'...: @contextlib.contextmanager def readonly(anobj): caller_globals = sys._getframe(2).f_globals saved_globals = caller_globals.copy() caller_globals.update((n, getattr(anobj, n)) for n in dir(anobj)) yield caller_globals.clear() caller_globals.update(saved_globals) and then, of course, with readonly(someobj): ... (local variables take precedence, and in particular all assignments define local variables, as usual -- but you can say e.g. 'zz' to mean 'someobj.zz', if you're sufficiently keen on giving up the advantage of having many well-separated namespaces;-). Alex On Sat, Jun 14, 2008 at 11:16 PM, Cesare Di Mauro [EMAIL PROTECTED] wrote: In data 15 giugno 2008 alle ore 02:24:43, Greg Ewing [EMAIL PROTECTED] ha scritto: ...and which should *not* be used in most cases, for the same reason. All those tutorials that start out with 'from something import *' are doing a lot of harm to the impressionable minds of new programmers, IMO. OK, but nobody have questioned about removing 'from something import *' just to help noobs... That's because the instruction *can* be useful in *some* (hopely limited, but existent) contexts. It's a matter of programmer choises. Anyway (and dropping my proposal), I think that the FAQ needs to be changed to advice that the 'with' keyword in Python makes a completely different kind of work. Cesare ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a with statement?
On Sat, Jun 14, 2008 at 1:24 PM, Simon Cross [EMAIL PROTECTED] wrote: On Sat, Jun 14, 2008 at 10:19 PM, Cesare Di Mauro [EMAIL PROTECTED] wrote: from Tkinter import * I discourage this too. :) And so do I, every single time I teach Python (which is pretty often, even though many of those cases don't make it into YouTube videos). I don't need to rant against it within Google, because Google's Python Style Guide already absolutely forbids it, fortunately;-). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Assignment to None
The problem is more general: what if a member (of some external object we're proxying one way or another) is named print (in Python 3), or class, or...? To allow foo.print or bar.class would require pretty big changes to Python's parser -- I have vague memories that the issue was discussed ages ago (possibly in conjunction with some early release of Jython) but never went anywhere much (including proposals to automatically append an underscore to such IDs in the proxying layer, etc etc). Maybe None in particular is enough of a special case (if it just happens to be hugely often used in dotNET libraries)? Alex On Mon, Jun 9, 2008 at 1:28 AM, Michael Foord [EMAIL PROTECTED] wrote: Steven D'Aprano wrote: On Mon, 9 Jun 2008 12:24:55 pm Curt Hagenlocher wrote: So, it's okay to setattr the attribute name None but not okay to set it directly? I suspect this is off-topic for python-dev, and would be better on comp.lang.python or similar, but for what it's worth, I consider having an attribute named 'None' bad practise, regardless of any runtime checks. But as part of Python's we're all consenting adults here philosophy, I wouldn't approve of expensive or extensive run-time checks specifically to prevent it. If you really have to name your attribute None, and are prepared to live with the consequences, then go ahead. FWIW Curt is asking because he is on the team responsible for implementing IronPython. In .NET you have several enumerations with members called None, for example 'Alignment.None'. It would be inconvenient for IronPython users if it enforced this particular syntax rule of Python's; that not only is assignment to None disallowed but that members named None are invalid syntax. The question is, what is the specification for Python. Is it that assignment to None is disallowed and the naming of members called None being invalid syntax is merely an artefact of the implementation of this, or does Python require this... Michael Foord In a similar fashion: class Parrot(object): ... pass ... p = Parrot() p.1 = 'spam' File stdin, line 1 p.1 ^ SyntaxError: invalid syntax setattr(p, '1', 'spam') ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mini-Pep: Simplifying the Integral ABC
On Fri, Jun 6, 2008 at 11:01 AM, Guido van Rossum [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 8:45 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: Does anyone actually need an int lookalike with binary methods but cannot just inherit from int? Does anyone actually need an int lookalike with operations like +, - etc. but cannot just inherit from int? If the answer is yes, is there a compelling reason why they wouldn't want to support binary methods as well? Yes, there's a use case for implementing long integers as arrays of decimal digits -- addition is roughly as efficient as for binary integers (x86 chips still have instructions to help with that), and emitting as decimal digits is MUCH more efficient of course -- so if I/O in decimal form is the most common operation, with a little arithmetic (particularly sums), you could gain performance; binary operations, however, would be as inefficient as decimal form conversion is for ordinary binary ints, and not needed for the typical applications that would use these decimal coded integers (accounting), so why not save the implementer of such an extension from having to write that unneeded and slow extra code? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Addition of pyprocessing module to standard lib.
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger [EMAIL PROTECTED] wrote: This thread has diverged a bit from the original topic. I suggest going ahead and adding pyprocessing to the library. IMO, its functionality is going to be an essential capability as more and more computers ship with multiple processors. At this point, the basic API for pyprocessing seems well thought-out and somewhat stable. Over time, I expect the implementation will get tweaked in a number of ways including support more platforms as developers figure-out that they like the idea enough to write some platform dependent patches. Putting this functionality in 2.6/3.0 would provide a really nice incentive to update from Py2.5. It would be a sad lost opportunity if this module had to wait another couple years. I feel essentially the same way: it WOULD be sad to waste this excellent opportunity, so I second the suggestion to put pyprocessing in the library right now. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Conditional For Statements
On Mon, May 19, 2008 at 5:33 AM, Steven D'Aprano [EMAIL PROTECTED] wrote:
...
import this
The Zen of Python, by Tim Peters
...
There should be one-- and preferably only one --obvious way to do it.
There should be ONE OBVIOUS way to do it, not only one way.
The only one way phrasing is in the Spirit of C section of the ISO
C Standard `Rationale' (non-normative, but highly informative),
specifically in point four, provide only one way to do an operation.
I contend that the somewhat different phrasing is somewhat accidental
and not particularly relevant: the *intent* of this *language design
guideline* is exactly the same (Tim was writing on his own, while the
C Standard was written by a committee, so it's hardly surprising that
the Standard's wording is drier and less funny than Tim's;-). IOW,
I've often argued that this is a deep commonality between the design
philosophy of C and Python (together with trust the programmer and
keep the language small and simple, two more points in the Spirit
of C section) which makes them conceptually closer to each other
than C is to languages sharing more of its syntax, from C++ to
Javascript; it should be particularly easy to see the contrast with
languages deliberately designed to provide multiple equivalent
synonyms (such as foo.size and foo.length meaning the same thing in
Ruby) or going out of their way to provide multiple equivalent syntax
approaches for exactly the same semantics (such as Cobol's ADD A TO B
GIVING C and C = A + B, or SQL's explicit [INNER] JOIN form and the
equivalent form where the inner join is left implicit in the WHERE
clause).
A design guideline is not a strict rule -- e.g., every C programmer
has met situations where a while statement, and a for statement with
some of the three subparts in the control clause omitted, can both
make sense, and of course every time you write within your loop some
if(condition) continue you wonder if in this case it might not be
better to instead use if(!condition) { ... } around the rest of the
loop's body, etc, etc -- so much for only one way, as the various
ways to perform elementary operations can click together in a large
number of combinations and permutations; and adding obvious would
not help much either, since both alternatives can easily happen to be
equally obvious. Python is just in the same situation. Nevertheless,
keeping the guideline firmly in mind (e.g., eschewing synonyms in APIs
you design that provide no added value beyond that of catering to
different tastes or to a meta-taste for variety over uniformity;-) is
still a helpful heuristic -- with or without the obvious word (i.e.,
whether you're working with C, which doesn't have the obvious in its
phrasing of the principle, or with Python, which does).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On Sun, May 4, 2008 at 3:31 AM, Raymond Hettinger [EMAIL PROTECTED] wrote: ... for k,g in groupby(iterable, key=lambda r: (r[0].lower(), r[5].lower())): ... lastname_firstname = lambda r: (r[0].lower(), r[5].lower()) for k, g in groupby(iterable, key=lastname_firstname): ... That transformation adds clarity. Going further and creating a separate def-statement outside the current function would just move the relevant code farther away and impair readability. And that would be totally silly and uncalled for -- why ever would it be placed *outside the current function*?! What a straw-man...! Just do def last_first(r): return r[0].lower(), r[5].lower() for k, g in groupby(iterable, key=last_first): ... putting the def right where you now have the name = lambda ... of course! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 8: Discourage named lambdas?
On Fri, May 2, 2008 at 11:32 PM, Mike Klaas [EMAIL PROTECTED] wrote:
...
Sorry, that was a bad example. It is obviously silly if the return value
of the function is callable.
...and yet it's *exactly* what keeps happening to lambda-happy
programmers -- in production code as well as examples, and in
major/famous projects too. E.g., a simple google code search shows
many Zope versions containing Bucket=lambda:{} instead of the
obvious Bucket=dict, Chandler with an intricate
t = threading.Thread(target=lambda x=activePort:testcon(x),verbose=0)
instead of
t = threading.Thread(target=testcon, args=(activePort,), verbose=0)
SQLAlchemy with callable_=lambda i: self.setup_loader(i) instead of
callable_=self.setup_loader ... apparently the existence of lambda
may easily blind one to the fact that one can simply pass a callable.
I guess that's inevitable (given lambda's existence... and human
nature;-) and about on the same plane as another hatefully redundant
construct I find myself having to beat upon over and over in code
reviews:
if expression:
result = True
else:
result = False
return result
vs the simple return expression [[or bool(expression) if it's
actually mandatory to return a bool and expression can't be relied
upon to produce one]].
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Invitation to try out open source code review tool
On Sat, May 3, 2008 at 2:28 PM, Brett Cannon [EMAIL PROTECTED] wrote: ... I'd be great to integrate this with the bug tracker so that all submitted patches automagically show up in codereview with links to one another. Yeah, or a simple button to move it over there. Either way some integration would be cool. Since this is being open-sourced we could probably have a python-dev instance installed that has all this bonus functionality for us if we can get an appspot account for the tracker team and there is some API we can tap into in order to create new issues. Given the app engine model, I guess any API to an app engine-hosted service would have to be of the RESTful kind, i.e., some URLs to which client-code can POST appropriately. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal(unicode)
On Tue, Mar 25, 2008 at 9:43 AM, Nick Coghlan [EMAIL PROTECTED] wrote: ... Since we have some strong use cases at least for the bytes-int case, consistency then suggests that the other numeric types should all accept bytes as well (interpreting them as ASCII encoded strings). +1 -- it seems very practical as well as consistent, and I see no downsides. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Improved thread switching
Hmmm, sorry if I'm missing something obvious, but, if the occasional background computations are sufficiently heavy -- why not fork, do said computations in the child thread, and return the results via any of the various available IPC approaches? I've recently (at Pycon, mostly) been playing devil's advocate (i.e., being PRO-threads, for once) on the subject of utilizing multiple cores effectively -- but the classic approach (using multiple _processes_ instead) actually works quite well in many cases, and this application server would appear to be one. (the pyProcessing package appears to offer an easy way to migrate threaded code to multiple-processes approaches, although I've only played around with it, not [yet] used it for production code). Alex On Wed, Mar 19, 2008 at 10:49 AM, Adam Olsen [EMAIL PROTECTED] wrote: On Wed, Mar 19, 2008 at 11:25 AM, Stefan Ring [EMAIL PROTECTED] wrote: Adam Olsen rhamph at gmail.com writes: So you want responsiveness when idle but throughput when busy? Exactly ;) Are those calculations primarily python code, or does a C library do the grunt work? If it's a C library you shouldn't be affected by safethread's increased overhead. It's Python code all the way. Frankly, it's a huge mess, but it would be very very hard to come up with a scalable solution that would allow to optimize certain hotspots and redo them in C or C++. There isn't even anything left to optimize in particular because all those low hanging fruit have already been taken care of. So it's just ~30kloc Python code over which the total time spent is quite uniformly distributed :(. I see. Well, at this point I think the most you can do is file a bug so the problem doesn't get forgotten. If nothing else, if my safethread stuff goes in it'll very likely include a --with-gil option, so I may put together a FIFO scheduler. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP Proposal: Revised slice objects lists use slice objects as indexes
On Mon, Mar 10, 2008 at 3:57 AM, Forrest Voight [EMAIL PROTECTED] wrote: I am not sure what you are trying to propose here. The slice object isn't special, it's just a regular built-in type. The idea is to have slice objects be generators. You could make a slice like 1:10:2 , and that would make a slice object which could be used as a list index. The list would return a list with the corresponding item for every index in the generator. Then, lists could And what indices would the slice 1:-1 return, for example? Your proposal can't play well with slices including negative indices. Also, your desired use case of alist[indices] is already pretty well covered by [alist[i] for i in indices]. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] RQST: Master Thesis
Depending on which implementation[s] you want to target, Michal, you should also check out PyPy at http://codespeak.net/pypy/, IronPython at http://www.codeplex.com/IronPython, and Jython at http://www.jython.org/ -- Jython's currently a tad behind the other three, but Sun Microsystems has just announced new investments and high-profile hires to make Jython a top-quality Python implementation. Alex On Sun, Mar 9, 2008 at 7:42 AM, [EMAIL PROTECTED] wrote: Michal I'm about to start my master thesis: optimizing python Michal interpreter therefore i would require your help plz ;) Michal first of all i need to find out, how the python interpreter is Michal implemented, and which are the related sources, if this stuff is Michal somewhere documented that would be very helpfull... Michal, The best place to start is the implementation of the interpreter itself (Python/ceval.c in the source tree) and the byte code compiler (Python/compile.c). There have, at times, been modest attempts to document what's going on, but I believe the source code is far and away still your best bet. I recommend you get a Subversion checkout of either the trunk: svn co http://svn.python.org/projects/python/trunk or the py3k branch: svn co http://svn.python.org/projects/python/branches/py3k You will find the trunk more stable, but the py3k branch is the future. Also, study the archives of this list and the [EMAIL PROTECTED] list as well as checkin comments for the Python source, especially for the two files I referenced above. Finally, there may well be pending patches in the Python tracker which implement various optimizations: http://bugs.python.org/ Studying them (and trying them out and attaching comments or reviews of their efficacy) would be a good way to help understand the system. -- Skip Montanaro - [EMAIL PROTECTED] - http://www.webfast.com/~skip/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C-API status of Python 3?
On Sun, Mar 2, 2008 at 10:39 AM, Gregory P. Smith [EMAIL PROTECTED] wrote: On 3/2/08, Christian Heimes [EMAIL PROTECTED] wrote: Alex Martelli wrote: Yep, but please do keep the PyUnicode for str and PyString for bytes (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the task of porting existing extensions... the bytearray functions should no doubt be PyBytearray, though. Yeah, we've already planed to keep PyUnicode as prefix for str type functions. It makes perfectly sense, not only from the historical point of view. But for PyString I planed to rename the prefix to PyBytes. In my opinion we are going to regret it, when we keep too many legacy names from 2.x. In order to make the migration process easier I can add a header file that provides PyString_* functions as aliases for PyBytes_* +1 on only doing this via a header that must be explicitly included by modules wanting the compatibility names. OK, as long as it's also supplied (and presumably empty) for 2.6 -- my key concern is faciitating the maintenance of a single codebase for C-coded Python extensions that can be compiled for both 2.6 and 3.0. (I'm also thinking of SWIG and similar utilities, but those can probably best be tweaked to emit rather different C code for the two cases; still, that C code will also include some C snippets hand-coded by the extension author/maintainer, e.g. via SWIG typemaps c, so easing the single codebase approach may help there too). I don't think we want to go the route of code translators/generators for C-coded Python extensions (the way we do for Python code via 2to3), and the fewer #if's and #define's C extension authors/maintainers are required to devise (in order to support both 2.6 and 3.0), the likelier it is that we'll see 3.0 support in popular C-coded Python extensions sooner rather than later. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] No releases tonight
On Sat, Mar 1, 2008 at 11:11 AM, Barry Warsaw [EMAIL PROTECTED] wrote: ... I also propose translations of the shorter text to important languages like French, German, Japanese, Portuguese and Spanish. I'm willing to help with the German translation. Cool, thanks. I'd like to volunteer for Italian (and we, the Italian Python community, do have reasonably good connections to the Italian technical press, which is covering e.g. the upcoming Pycon Due conference), and although my French is VERY rusty I can give it a try if no native French speaker is forthcoming. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] C-API status of Python 3?
On Sat, Mar 1, 2008 at 12:14 PM, Christian Heimes [EMAIL PROTECTED] wrote: ... The 3.0 API isn't stable yet. I plan to rename some of the functions before the first beta is released. Currently the naming schema is too confusing: PyUnicode - str PyString - bytes PyBytes - bytearray See? :) Yep, but please do keep the PyUnicode for str and PyString for bytes (as macros/synonnyms of PyStr and PyBytes if you want!-) to help the task of porting existing extensions... the bytearray functions should no doubt be PyBytearray, though. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python developers are in demand
On 10/12/07, Martin v. Löwis [EMAIL PROTECTED] wrote: The problem may be related to the fact that Python is rarely teached at school or university. I know no school or university in Germany that is teaching Python. I teach Python to the first semester, at the Hasso-Plattner-Institut in Potsdam, for the third year now. My wife (and fellow PSF member;-) Anna, a major in Symbolic Systems at Stanford, has noticed the interesting coincidence that TWO of her courses this quarter suggest Python as the preferred language to do the course assignments (although both courses accept other languages as well, focusing on the results and not the language used to achieve them, the teachers think that Python is the best language to get out of your way and let you focus on the courses' specific subjects rather than on programming problems). The two courses are Computational Linguistics and Computer-Human Interactions. The CHI course also offers a short optional Python seminar for students that want help learning it (I believe the exercises specifically use Nokia phones, so I assume the seminar will also cover the specifics of the Nokia Python development environment); Anna volunteered to do a similar short seminar for the CL course (I helped out -- took us a Saturday). All students taking CHI and/or CL have already taken programming courses (typically more than one), mostly using C++ and Java (and often C), but as far as I know there is no Stanford course (at least not within Symbolic Systems) that focuses specifically and exclusively on Python (there IS one course, Programming Paradigms, that covers Python as well as Lisp, Prolog and some FP language). Of course, Symbolic Systems majors typically don't think of themselves as developers; they're more likely to end up, say, as CHI experts, computational linguists, and the like... Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] weakref enhancements
On 9/28/06, tomer filiba [EMAIL PROTECTED] wrote: I'm sceptical that these would find use in practice. [..] Also, I question the utility of maintaining a weakref to a method or attribute instead of holding one for the object or class. As long as the enclosing object or class lives, so too will their methods and attributes. So what is the point of a tighter weakref granualarity? i didn't just came up with them out of boredom, i have had specific use cases for these, mainly in rpyc3000... but since the rpyc300 code base is still far from completion, i don't want to give examples at this early stage. however, these two are theoretically useful, so i refactored them out of my code into recipes. I've had use cases for weakrefs to boundmethods (and there IS a Cookbook recipe for them), as follows: sometimes I'm maintaining a container of callables, which may be of various kinds including functions, boundmethods, etc; but I'd like the mere presence of a callable in the container not to keep the callable alive (especially when the callable in turn keeps alive an object with possibly massive state). In practice I use wrapping and tricks, but it would be nice to have cleaner standard library support for this. (Often the container needs to be some form of a Queue.Queue, since queues of callables are a form I use very often to dispatch work requests to worker-threads in a threadpool). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Can LOAD_GLOBAL be optimized to a simple array lookup?
On Aug 23, 2006, at 2:22 PM, K.S.Sreeram wrote: Hi all, I noticed in Python/ceval.c that LOAD_GLOBAL uses a dictionary lookup, and was wondering if that can be optimized to a simple array lookup. If i'm right there are 3 kinds of name lookups: locals, outer scopes(closures), and globals. (not counting attribute lookup). Locals are identified by, either the presence of assignments, or their presence in the arg list. So all name lookups can be classified into the 3 types at compile/load time. Since we know, at load time, which names are global.. Can't we simply build a global name table and replace LOAD_GLOBALs with a lookup at the corresponding index into the global name table? At the time the function's body gets compiled, the global (or builtin) it's trying to access might or might not be there -- as long as it gets added afterwards, before the function's body gets _executed_, no problem (in today's scheme). It's not obvious to me how you could compile a ``corresponding index'' into the LOAD_GLOBAL opcode, since that index is in general unknown at compile time. The module's dict object will need to be special so that whenever a name gets 'set', the global name table should get updated. It seems that you'd need to chase down and modify all of the LOAD_GLOBAL opcodes too, at every such modification. (the concept of modifying builtins becomes extremely scary...). Considering the amortized speed of a dict lookup for an interned string (hash value cached and thus immediately available, equality comparison with other interned string a single machine-level operation), it's not clear to me that the huge complexity (and potential performance impact) of all this could ever possibly be justified. A change in Python semantics allowing some level of nailing down of builtins (and perhaps globals too) *COULD* easily yield large performance benefits, but that's a subject for the Python-3000 mailing list; as long as builtins and globals stay as fluid as today, I'm skeptical on the optimization opportunities here. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c
On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote: Since Alex isn't on python-dev, forwarding this for his convenience (he said he wanted to reply.) Thanks! I _am_ on Python-Dev (otherwise couldn't read what you're forwarding here), but not on Python-Checkins (where the discussion was started). Tim also replied to his checkin, but I didn't forward that message. Yep, saw that (thanks Brett) -- if I read him right, Tim was basically suggesting better ways to check for infinity rather than saying it's better to keep today's inconsistency (he can surely correct me if I misread). Tim is of course right, but PEP 754 (the fpconst module) would appear to be the right way to perform the checking, anyway. I don't think this can be right. The returnvalue of pow() in the case of ERANGE isn't defined anywhere that I can find, at least. How can we assume it is +Infinity? As I tried to say over the visiphone, you can't even use compile- That's how I read ISO/IEC 9899:1999 7.12.1.4 , which is describing C's math functions in general: If a floating result overflows and default rounding is in effect, or if the mathematical result is an exact infinity (for example log (0.0)), then the function returns the value of the macro HUGE_VAL, HUGE_VALF, or HUGE_VALL according to the return type, with the same sign as the correct value of the function; etc. Yes, that's a C language standard that's just 7 years old, rather than the 16-years-old standard Python can definitely count on; but we could presumably test (and rely on) __STDC_IEC_559__ if we need features in Appendix F, or just on __STDC_VERSION__ being defined and = 199901L for more generic parts of the standard (such as the part I was quoting above from chapter 7). People who build Python with C compilers not meeting these macro criteria but still good enough to afford a minimally functional implementation of IEEE 754 floats might run configure with some appropriate -with-whatever options to assert the fact, if needed (i.e., if either because of C 1990 Standard language, or realworld brokenness of important compilers, automatic tests are in fact unreliable). And PEP 754 (and thus fpconst, or some other way for Python code to tell if it's running on a minimally functional implementation of IEEE 754 floats, and if so test for and generate NaNs and infinities) should also be there so that the Python-coded unittests can properly decide whether to test for compliance. time or startup-time checks for the behaviour because 'undefined' also means it need not be consistent, either. The Yes, but the behavior is not undefined in standard C (1999 standard; I don't have access to the 1990 standard) best we could do, if we really wanted to return +inf instead of raising OverflowError (which I don't, but don't really care about either), is generate +Infinity in some guaranteed way. I'm sure Tim can come up with a convenient, portable way 0.9 wink. The macro Py_HUGE_VAL seems to be the documented way to do it. And while I'd rather uniformly get infinity from operations producing infinity, what I'm really keen to avoid is having one such operation raise an exception while another one succeeds. But I'd prefer to keep it the way it was: x*x and x**2 don't always do the same thing. Floats have a lot more confusing features like that, such as 10*x - 9*x need not be x. I don't see the added value of trying to make it consistent in just this case, even if it's portable. There's a huge conceptual gap between, on one side, two values produced by roughly equivalent expressions being only *ALMOST* equal rather than strictly equal, and one of the expressions raising an exception while the other one happily proceeds. The former case is reasonably easy to handle -- that's why we have an assertAlmostEqual method in unittest.TestCase; the latter can be a nightmare. The same goes for the other bug I recently added to the tracker, the x != y and [x] == [y] one. Of course, according to this more confusing features philosophy, I guess it can be considered quite OK to leave in Python absurdities like this one, as well. I abhor that whle slippery slope philosophy (there's a tiny unavoidable problem in this corner so it's OK to leave a huge gaping hole all over the place) but I see no way to resolve such philosophical conflict without BDFL pronouncement. So, I have reverted r51525; I now believe it can't be done right (with proper unittests) without PEP 754 or something like that, anyway. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r51525 - in python/trunk:Lib/test/test_float.py Objects/floatobject.c
On Aug 23, 2006, at 3:13 PM, [EMAIL PROTECTED] wrote: Zitat von Tim Peters [EMAIL PROTECTED]: Huh. It's been a (mildly controversial, but intentional all the same) feature that Python tries to raise raise OverflowError on overflowing libm operations. Doesn't work all that well, since there's no consistency across platforms about when libm sets errno, or to what (when it does). The other question is whether pow() is guaranteed to return inf when it sets errno to ERANGE; I believe there is no such guarantee. Summarizing my longer mail that crossed with yours: the guarantee is there in the 1999 C Standard; I don't have access any more to a copy of the 1990 C Standard to check how things were back then. So I think the change should be reverted. I have reverted the change, but I think it (or rather something like it -- *SOME* fix for x**2 raising OverflowError while x*x proceeds happily for a certain range of floats) is important and should go back in again. Using Py_HUGE_VAL instead of trusting pow's result might be OK, for example, if the 1990 C Standard is that much weaker on this than 1999's and we need to stick to it anyway. But the problem is that testing this sensibly requires fpconst (from PEP 754) or the equivalent, otherwise it may be impossible to write unittest to show the presence or absence of this bug. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ctypes and win64
On Aug 19, 2006, at 3:28 AM, Steve Holden wrote: ... It's going to be very interesting to see what comes out of the Google sprints. I am sure the 64-bitters will be out in force, so there'll be Hmmm, we'll be working on our laptops, as is typical of sprints, so I'm not sure how many 64-bit machines will in fact be around -- we'll see. useful data about any such problems. irony wink=0.9764 bits is, I am sure, as much as anyone is ever going to need, so the pain will finally be over./irony It's good to see the idea of industry support for open source sprints taking off. Tomorrow, the world ... :-) Sprints are indeed a fascinating idea and have proven they work, in an open-source context -- I do wonder if they could be made to work in other contexts, and I'm sure many others are wondering similarly. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Time-out in URL Open
What about doing it with a per-thread-timeout in TLS (overriding the global one if a thread does have it set in its TLS)? Not as clean, but perhaps far easier to implement than patching dozens of modules/functions/classes to provide timeout= options everywhere... Alex On 7/5/06, Guido van Rossum [EMAIL PROTECTED] wrote: OK, you've convinced me. Now where's that SF patch you were promising? :-) --Guido On 7/5/06, Facundo Batista [EMAIL PROTECTED] wrote: 2006/7/4, Guido van Rossum [EMAIL PROTECTED]: This affect all the sockets. So, assuming your app is single-threaded, set the timeout, call urlopen(), and reset the timeout to None. No, it's multithreaded, :D And I hit the problem when servicing information with a web service (TCPServer), and I need to timeout the connection of the URLOpen *only*. That's not so easy even if you were to have a timeout parameter to urlopen(). You'd have to implement that peculiarity in all the layers (in this case, urllib and httplib; and possibly ftplib, gopherlib etc. :-) Yes, it's not SO easy, because, as you said, you have to dig into the layers until you hit the actual socket creation and modify the timeout for that socket only. That's why I think that this should be handled in the standard library and not left to implement to whoever will need it, :) -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Import semantics
In Italian that would be DBAV (Dittatore benevolo a vita)...;-) Alex On 7/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Frank That said, I still regard Samuele Pedroni as the ultimate Frank authority on Jython and give him pretty much full veto power. He Frank fortunately continues to watch the checkins and prods me when I Frank go in the wrong direction. Does that make Samele the DBPV (Dictator benevolo per vita)? ;-) Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/aleaxit%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Switch statement
On 6/22/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... (1) An expression of the form 'static' atom has the semantics of evaluating the atom at the same time as the nearest surrounding function definition. If there is no surrounding function definition, 'static' is a no-op and the expression is evaluated every time. [Alternative 1: this is an error] [Alternative 2: it is evaluated before the module is entered; this would imply it can not involve any imported names but it can involve builtins] [Alternative 3: precomputed the first time the switch is entered] +1, preferably with alternative 1. I've occasionally (ab)used the fact that default values are computed at def time to get similar semantics, but that (whence the ab) has all sorts of issues (such as exposing arguments you really do NOT want to be passed). (2) All case expressions in a switch have an implied 'static'. (3) A switch is implemented using a dict which is precomputed at the same time its static expressions are precomputed. The switch expression must be hashable. Overlap between different cases will raise an exception at precomputation time. +0, just because I care about switch only up to a point!-) Independent from this, I wonder if we also need static names of the form static name = expression which would be similar to name = static (expression) but also prevents name from being assigned to elsewhere in the same scope. Lovely!!! Definitely +1. Could perhaps THIS use of static be allowed even outside of a def? I'd just love to have such static names in modules and classes, too (with runtime checks of errant assignments, if needed). Also, I haven't heard a lot of thumbs up or down on the idea of using case X: to indicate a single value and case in S: to indicate a sequence of values. (I'm not counting all the hypergeneralizations that were proposed like case == X: case X: case is X: case isinstance X: since I'm -1 on all those, no matter how nicely they align. Agreed on the generalizations, but allowing (just) case == X and case in S looks more readable to me than case X and case in S. Since I'm not overly focused on switch/case anyway, _and_ this choice is just about syntax sugar anyway, my preference's mild!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] a note in random.shuffle.__doc__ ...
...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. Now -- why would the behavior of most random number generators be relevant here? The module's docs claim, for its specific Mersenne Twister generator, a period of 2**19997-1, which is (e.g.) a comfortable 130128673800676351960752618754658780303412233749552410245124492452914636 028095467780746435724876612802011164778042889281426609505759158196749438 742986040468247017174321241233929215223326801091468184945617565998894057 859403269022650639413550466514556014961826309062543 times larger than the number of permutations of 2000 items, which doesn't really feel to me like a rather small len(x) in this context (what I'm most often shuffling is just a pack of cards -- len(x)==52 -- for example). I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a note in random.shuffle.__doc__ ...
On Jun 10, 2006, at 1:08 PM, Josiah Carlson wrote: Josiah Carlson [EMAIL PROTECTED] wrote: Alex Martelli [EMAIL PROTECTED] wrote: ...claims: Note that for even rather small len(x), the total number of permutations of x is larger than the period of most random number generators; this implies that most permutations of a long sequence can never be generated. [snip] I suspect that the note is just a fossil from a time when the default random number generator was Whichman-Hill, with a much shorter period. Should this note just be removed, or instead somehow reworded to point out that this is not in fact a problem for the module's current default random number generator? Opinions welcome! I'm recovering from a migraine, but here are my thoughts on the topic... The number of permutations of n items is n!, which is (n/2)^(n/2). Solve: 2**19997 (n/2)^(n/2) log_2(2**19997) log_2((n/2)^(n/2)) 19997 (n/2)*log(n/2) Certainly with n = 4096, the above holds (2048 * 11 = 22528) - Josiah I would also point out that even if MT had a larger period, there would still be no guarantee that all permutations of a given sequence would be able to be generated from the PRNG given some aribtrary internal state. Sure. And an n of 2081 happens to suffice: period = 2**19937 while gmpy.fac(i) period: i = i +1 ... i 2081 Still, the note, as worded, is misleading -- it strongly suggests that for even small len(x) (no mention of whether that means dozens or thousands) the RNG can't generate all permutations, with no proof either way and just a misleading hint. The values of N such that the RNG can generate all permutations of a sequence of len(N) are not precisely known at this time might be closer to the truth (if this is, indeed, the state of our collective knowledge). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] epoll implementation
On May 26, 2006, at 6:27 PM, Steve Holden wrote: Greg Ewing wrote: Fredrik Lundh wrote: roughly speaking, epoll is kqueue for linux. There are many different select-like things around now (select, poll, epoll, kqueue -- are there others?) and random combinations of them seem to be available on any given platform. This makes writing platform-independent code that needs select-like functionality very awkward. Rather than adding yet another platform-dependent module, I'd like to see a unified Python interface in the stdlib that uses whichever is the best one available. Of course that would mean establishing which *was* the best available which, as we've seen this week, may not be easy. I believe it's: kqueue on FreeBSD (for recent-enough versions thereof), otherwise epoll where available and nonbuggy, otherwise poll ditto, otherwise select -- that's roughly what Twisted uses for Reactor implementations, if memory serves me well. The platform- based heuristic should try to identify things this way but let the developer easily override if they know better. (One might add a Windows event loop as the best implementation available there -- Twisted does -- and GUI toolkit based event loops -- but in general that takes an abstraction level similar to Twisted's Reactor... maybe we should just repurpose that bit of Twisted?-) I don't think this is feasible for 2.5 (too late in the cycle to add major new stuff, IMHO), but it's well worth it for 2.6 (again IMHO). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
On Apr 24, 2006, at 5:13 AM, John J Lee wrote: On Mon, 24 Apr 2006, Paul Moore wrote: On 4/24/06, Neil Hodgson [EMAIL PROTECTED] wrote: Martin v. Löwis: Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? [...] No. Martin means that http://msdn.microsoft.com/visualc/ vctoolkit2003/ no longer points to a downloadable version of MSVC which includes the optimizer, and generates VC 7.1 compatible binaries. This means that unless you've already downloaded it, or it's acceptable for someone else to host it, there's once again no way to build Python with free tools :-( [...] Actually, it's apparently still there, just at a different URL. Somebody posted the new URL on c.l.py a day or two back (Alex Martelli started the thread, IIRC). I'm off to the dentist, no time to Google for it! Yep, I was the one looking for that URL, and then at somebody else's request reposted it and also tinyurled it (since it's a very long URL it gives somebody problems). For the Toolkit 2003: http://tinyurl.com/gv8wr Also, for the Net SDK 1.1 (the 2.0 one apparently now is lacking the msvcrt.lib for x86...): http://tinyurl.com/5flob (original Url for the latter kindly supplied by Martin, btw). Martin also suggested using mingw instead, on that same thread. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
On Apr 24, 2006, at 12:19 AM, Martin v. Löwis wrote: Martin v. Löwis wrote: - Paul Moore has contributed a Python build procedure for the free version of the 2003 compiler. This one is without IDE, but still, it should allow people without a VS 2003 license to work on Python itself; it should also be possible to develop extensions with that compiler (although I haven't verified that distutils would pick that up correctly). Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? Personally, being a cheapskate, and with Windows only my tertiary system, I'm in favor of anything that makes it simpler and/or cheaper for people to work on Python and extensions. However, by the same token I cannot really gauge how stable and solid VS 2005 is -- if as current Windows experts you think it's still inferior to VS 2003, then that's a very big point against it. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
On Apr 24, 2006, at 12:48 AM, Neil Hodgson wrote: Martin v. Löwis: Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? I expect Microsoft means that Visual Studio Express will be available free forever, not that you will always be able to download Visual Studio 2005 Express. They normally only provide a particular product version for a limited time after it has been superceded. Yeah, that does sound like a normal commercial policy. If we want some compiler to be available forever, we have to choose one that we can get permission to redistribute, and host it somewhere ourselves. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Visual studio 2005 express now free
On Apr 24, 2006, at 1:24 AM, Paul Moore wrote: On 4/24/06, Neil Hodgson [EMAIL PROTECTED] wrote: Martin v. Löwis: Apparently, the status of this changed right now: it seems that the 2003 compiler is not available anymore; the page now says that it was replaced with the 2005 compiler. Should we reconsider? I expect Microsoft means that Visual Studio Express will be available free forever, not that you will always be able to download Visual Studio 2005 Express. They normally only provide a particular product version for a limited time after it has been superceded. No. Martin means that http://msdn.microsoft.com/visualc/vctoolkit2003/ no longer points to a downloadable version of MSVC which includes the optimizer, and generates VC 7.1 compatible binaries. This means that unless you've already downloaded it, or it's acceptable for someone else to host it, there's once again no way to build Python with free tools :-( I've posted a couple of tinyurl's that may help (no time right now to try everything out again myself). (Is it worth the PSF asking MS if it's acceptable for python.org to host a copy of the toolkit compiler? As MS donated copies of MSVC 7.1 to the Python project, they may be willing to consider this...) Small as the chance may be, it's still most definitely worth asking, so that everything doesn't suddenly break the instant MS wants to withdraw the URLs that currently still work. Also, we'd need the ability to redistribute the 1.1 SDK, as the 2.0 one seems to lack the key msvcrt.lib for x86. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.
On Apr 21, 2006, at 7:46 AM, Aahz wrote: On Fri, Apr 21, 2006, Mateusz Rukowicz wrote: Next thing I would add is multi precision floating point type to the core and fraction type, which in some cases highly improves operations, which would have to be done using floating point instead. Of course, math module will need update to support multi precision floating points, and with that, one could compute asin or any other function provided with math with precision limited by memory and time. It would be also good idea to add function which computes pi and exp with unlimited precision. And last thing - It would be nice to add some number-theory functions to math module (or new one), like prime-tests, factorizations etc. To echo and amplify what Guido said: an excellent project would be to rewrite the decimal module in C. Another option would be to pick up and enhance either of the GMP wrappers: http://gmpy.sourceforge.net/ http://www.egenix.com/files/python/mxNumber.html That would also deal with your suggestion of rational numbers. GMP is covered by LGPL, so must any such derivative work (presumably ruling it out for embedding in Python's core itself). That being said, as gmpy's author, I'd be enthusiastically happy to mentor anybody who wants to work on gmpy or other multiprecision arithmetic extension for Python. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Google Summer of Code proposal: improvement of long int and adding new types/modules.
On 4/21/06, Mateusz Rukowicz [EMAIL PROTECTED] wrote: ... So I think the most valuable of my ideas would be improving long int + coding decimal in C. Anyway, I think it would be possible to add other ideas later. I see redo Decimal in C (possibly with the addition of some fast elementary transcendentals) and enhance operations on longs (multiplication first and foremost, and base-conversions probably next, as you suggested -- possibly with the addition of some fast number-theoretical functions) as two separate projects, each of just about the right magnitude for an SoC project. I would be glad to mentor either (not both); my preference would be for the former -- it appears to me that attempting to do both together might negatively impact both. Remember, it isn't just the coding...: thorough testing, good docs, accurate performance measurements on a variety of platforms, ..., are all important part of a project that, assuming success, it's scheduled to become a core part of Python 2.6, after all. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5 post-alpha1 broken on mac-intel machines
Back from vacation, just did an svn up and make, and...: ... gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o Parser/ firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o Python/ mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o Parser/ pgenmain.o -ldl -o Parser/pgen /usr/bin/ld: warning Parser/printgrammar.o cputype (18, architecture ppc) does not match cputype (7) for specified -arch flag: i386 (file not loaded) /usr/bin/ld: Undefined symbols: __Py_printgrammar __Py_printnonterminals collect2: ld returned 1 exit status make: *** [Parser/pgen] Error 1 No idea where that deuced architecture ppc comes from, since this Mac (a Macbook Pro) has an intel CPU -- I assume some configuration file erroneously posits that Macs must have PPC processors (which has been false for many months and was not posited in alpha-1, which compiled fine here). Too tired to look more into this (having just driven back from a week's vacation in the Grand Canyon), but I will next week if I have to...:-( Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The i string-prefix: I18n'ed strings
On 4/6/06, Martin Blais [EMAIL PROTECTED] wrote:
...
So I had the following idea: would it not be nice if there existed a
string-prefix 'i' -- a string prefix like for the raw (r'...') and
unicode (u'...') strings -- that would mark the string as being for
i18n? Something like this (reusing my example above)::
+1: having helped out with substantial amounts of i18n work over the
years, I agree with you 100% that this addition would give substantial
benefits.
- We could also have a prefix I for strings to be marked but not
runtime-translated, to replace the N_() strings.
I'm more dubious about this one, because I don't really see the point.
Expand pls? With a couple of use cases, maybe?
- My impression is that this process of i18n is common enough that it
does not move very much, and that there aren't 18 ways to go about
it either, so that it would be reasonable to consider adding it to the
language. This may be completely wrong, I am by no means an i18n
expert, please show if this is not the case.
My experience agrees with your assessment regarding the first half of
the proposal (but I don't get the second half, I think).
Okay, let's push it further a bit: how about if there was some kind
of generic mechanism built-in in Python for adding new string-prefixes
which invoke callbacks when the string with the prefix is evaluated?
I think this one is an idea for Python 3000: you should probably post
it to that mailing list.
This could be used to implement what I'm suggesting above, and beyond.
Something like this::
import i18n
i18n.register_string_prefix('i', _)
i18n.register_string_prefix('I', N_)
I'm not sure what else we might be able to do with this, you may have
other useful ideas.
Oh, plenty of things, such as d'123.45' as a syntax for decimal
literals (or viceversa for binary floats, if decimals become the Py3k
default), q'123/54' for rationals (today's gmpy.mpq('123/54') or other
implementations), etc. Ideas which have little to do with i18n,
mostly. It's exactly because of the broad impact of such a mechanism
(and, inevitably, the possibility of abuse and overuse) that I think
it's Py3k material, not 2.* stuff.
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tally (and other accumulators)
On Apr 4, 2006, at 10:53 PM, Jess Austin wrote: Alex wrote: import collections def tally(seq): d = collections.defaultdict(int) for item in seq: d[item] += 1 return dict(d) I'll stop lurking and submit the following: def tally(seq): return dict((group[0], len(tuple(group[1]))) for group in itertools.groupby(sorted(seq))) In general itertools.groupby() seems like a very clean way to do this sort of thing, whether you want to end up with a dict or not. I'll go so far as to suggest that the existence of groupby() obviates the proposed tally(). Maybe I've just coded too much SQL and it has warped my brain... OTOH the latter definition of tally won't cope with iterables, and it seems like O(nlogn) rather than O(n). It will cope with any iterable just fine (not sure why you think otherwise), but the major big-O impact seems to me to rule it out as a general solution. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elementtree in stdlib
On Apr 5, 2006, at 8:30 PM, Greg Ewing wrote: A while ago there was some discussion about including elementtree in the std lib. I can't remember what the conclusion about that was, but if it does go ahead, I'd like to suggest that it be reorganised a bit. I've just started playing with it, and having a package called elementtree containing a module called ElementTree containing a class called ElementTree is just too confusing for words! Try the 2.5 alpha 1 just released, and you'll see that the toplevel package is now xml.etree. The module and class are still called ElementTree, though. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] tally (and other accumulators)
It's a bit late for 2.5, of course, but, I thought I'd propose it anyway -- I noticed it on c.l.py. In 2.3/2.4 we have many ways to generate and process iterators but few accumulators -- functions that accept an iterable and produce some kind of summary result from it. sum, min, max, for example. And any, all in 2.5. The proposed function tally accepts an iterable whose items are hashable and returns a dict mapping each item to its count (number of times it appears). This is quite general and simple at the same time: for example, it was proposed originally to answer some complaint about any and all giving no indication of the count of true/false items: tally(bool(x) for x in seq) would give a dict with two entries, counts of true and false items. Just like the other accumulators mentioned above, tally is simple to implement, especially with the new collections.defaultdict: import collections def tally(seq): d = collections.defaultdict(int) for item in seq: d[item] += 1 return dict(d) Nevertheless, simplicity and generality make it advisable to supply it as part of the standard library (location TBD). A good alternative would be a classmethod tally within collections.defaultdict, building and returning a defaultdict as above (with a .factory left to int, for further possible use as a 'bag'/multiset data structure); this would solve the problem of where to locate tally if it were to be a function. defaultdict.tally would be logically quite similar to dict.fromkeys, except that keys happening repeatedly get counted (and so each associated to a value of 1 and upwards) rather than collapsed. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tally (and other accumulators)
On Apr 4, 2006, at 8:01 AM, Jeremy Hylton wrote: On 4/4/06, Alex Martelli [EMAIL PROTECTED] wrote: import collections def tally(seq): d = collections.defaultdict(int) for item in seq: d[item] += 1 return dict(d) ... Putting it somewhere in collections seems like a great idea. defaultdict is a bit odd, because the functionality doesn't have anything to do with defaults, just dicts. maybe a classmethod on regular dicts would make more sense? Good points: it should probably be a classmethod on dict, or a function in module collections. I write this function regularly, so I'd be happy to have it available directly. Heh, same here -- soon as I saw it proposed on c.l.py I recognized an old friend and it struck me that, simple but widely used, it should be somewhere in the standard library. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] tally (and other accumulators)
On 4/4/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Alex] This is quite general and simple at the same time: for example, it was proposed originally to answer some complaint about any and all giving no indication of the count of true/false items: tally(bool(x) for x in seq) would give a dict with two entries, counts of true and false items. FWIW, sum() works nicely for counting true entries: sum(x%3==0 for x in range(100)) 34 Sure, and also works fine for counting false ones, thanks to 'not', but if you need both counts sum doesn't work (not without dirty tricks that can't be recommended;-). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
On Mar 27, 2006, at 7:20 AM, Raymond Hettinger wrote: Why don't we expose _PySet_Next() for Barry and leave it out of the public API for everyone else. There are precedents for adding some functionality to the C API but not documenting it to ensure non advanced users don't get hurt -- that's how we added the ability to raise exceptions in different threads, in particular. Not sure if this is the best solution here, but I'm just pointing out that it's definitely not unthinkable, procedurally speaking. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
On Mar 26, 2006, at 8:43 AM, Raymond Hettinger wrote: [Aahz] Speaking as a person who does relatively little C programming, I don't see much difference between them. The first example is more Pythonic -- for Python. I agree with Barry that it's not much of a virtue for C code. It was a trick question. Everyone is supposed to be attracted to the _next version because it is shorter, faster, and takes less ref counting management. However, the _next version has a hard-to-find bug. The call to PyObject_Hash() can trigger arbitrary Python code and possibly mutate the table, leaving pointers to invalid memory addresses. It would likely take Armin less than five minutes to write a pure Python crasher for the code. And THAT is why PySet_Next() should never come into being. Sure, accidentally mutating underlying iterables is a subtle (but alas frequent) bug, but I don't see why it should be any harsher when the loop is using a hypothetical PySet_Next than when it is using PyIter_Next -- whatever precautions the latter takes to detect the bug and raise an exception instead of crashing, wouldn't it be at least as feasible for PySet_Next to take similar precautions (probably easier, since PySet_Next need only worry about one concrete case rather than an arbitrary variety)? What does PyDict_Next do in similar cases, and why couldn't PySet_Next behave similarly? (Yes, I could/should look it up myself, but I'm supposed to be working on the 2nd Ed of the Nutshell, whose deadline is getting worryingly close...;-). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySet API
On Mar 25, 2006, at 9:57 PM, Aahz wrote: I'd really like to see someone else who understands the issues (i.e. using the Python C-API) weigh in. Both Barry and Raymond are clever programmers who generally understand what's Pythonic, and I find myself agreeing with whoever posted last. ;-) Having another perspective would probably shed some light here. My general preference is rather well-known, and I quote the advice I gave in Python in a Nutshell...: Some of the functions callable on specifically-typed objects [...] duplicate functionality that is also available from PyObject_ functions; in these cases, you should almost invariably use the more general PyObject_ function instead. I don’t cover such almost- redundant functions in this book. However, I don't go as far as suggesting PyObject_CallMethod and the like... I'd much rather have abstract-layer PyObject_... functions, as long as they're applicable to two or more concrete built-in types (for example, IMHO adding PyObject_Clear is a no-brainer -- it's obviously right). And I'm on the fence regarding the specific issue of PySet_Next. So, having carefully staked out a position smack in the middle, I cheerfully now expect to be fired upon from both sides!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
On Mar 19, 2006, at 7:42 PM, Guido van Rossum wrote: ... There seem to be other places where Python is beginning to require parens even though they aren't strictly necessary to resolve syntactic ambiguity. In the style guide only, I hope. The parens that are mandatory in a few places *are* necessary to resolve ambiguity. Technically, I believe the first place where this did not apply was list comprehensions, back in 2.2, since (for example) [x, y for y, x in whatever] could have been syntactically disambiguated but (quite reasonably, IMHO) [(x,y) for y,x in whatever] was mandated instead. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py3k: Except clause syntax
On Mar 16, 2006, at 7:30 PM, Brett Cannon wrote: ... I agree. as is taking on the use of assignment in statements that are not ``=`` and I say we just keep on with that. Plus Greg's above Hmmm, if we allowed '(expr as var)' for generic expr's we'd make a lot of people pining for 'assignment as an expression' very happy, wouldn't we...? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are so many built-in types inheritable?
On Mar 13, 2006, at 12:29 PM, Fabiano Sidler wrote: Hi folks! Hello Fabiano! The proper venue for your interesting issues is comp.lang.python (or the equivalent mailing list), where all sorts of people will be able to hear you, discuss things, and help out. python-dev is strictly for developers of Python itself, so please re- post your issues to comp.lang.python. Thanks, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module patch
On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] as mania
On Mar 7, 2006, at 6:15 AM, Georg Brandl wrote: Hi, while as is being made a keyword, I remembered parallels between with and a proposal made some time ago: with expr as f: do something with f while expr as f: do something with f if expr as f: do something with f elif expr as f: do something else with f What do you think? I think the best use cases for 'assignment inside an if or while' condition, as far as they go, require `capturing' a SUB-expression of the condition, rather than the whole condition. E.g., in C, while ( (x=next_x()) threshold ) ... being able to capture (by `as') only the whole (true or false) condition meets a minority of the use cases, so I'm unenthusiastic about it. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
On Mar 7, 2006, at 7:29 AM, Steve Holden wrote: ... In fact, I think the below examples are reasonable uses that do a better job of expressing intent than the if statement would. I just don't like the mental backtrack they require, and would like some sort of advance warning. Parentheses at least tell me You're not done yet; keep reading. ack(r,r) if r not in cache log(message) if error_flag I think you've misunderstood the nature of the change. HTe new conditionals are *expressions*, they aren't postfix conditionals for statements. Right, but the only effect of that on the examples is that they both need an 'else None' continuation or thereabouts. I also predict widespread over-use of the new toy and agree with Jim that mandatory parentheses around the whole (X if Y else Z) construct would ameliorate legibility a bit. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] collections.idset and collections.iddict?
On Mar 6, 2006, at 4:43 PM, Bob Ippolito wrote: On Mar 6, 2006, at 4:14 PM, Guido van Rossum wrote: ... I wonder if this use case and the frequently requested case-insensitive dict don't have some kind of generalization in common -- perhaps a dict that takes a key function a la list.sort()? +1. I've wanted such a thing a couple times, and there is some precedent in the stdlib (e.g. WeakKeyDictionary would be a lot shorter with such a base class). Seconded -- though at least in the cases I remember better what I really needed was a _list_ with such functionality (order was significant, but I wanted 'in'-tests and find and remove calls to work by id, not by ==) -- I ended up with a somewhat more complicated solution (not just a list subclass, though that might perhaps be simpler). In the case where I needed a dict, I inherited from DictMixin and delegated some methods (with id(key) instead of key) to a self.somedict -- if a dict could be built with a key function, the solution would be both simpler and faster. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] Python humor
On Mar 6, 2006, at 10:17 AM, Tim Peters wrote: ... How's everyone doing, BTW? Swimmingly, thanks! Too busy to breathe, or come to pycon:-(, but, happy as a lark. I think I picked up the Texas Mystery Disease from Holger Krekel -- bed-ridden 20 hours Saturday, and most of Sunday, with dry cough and high fever. Or that's just a normal outcome of sprinting :-) I got vaccinated against flu in Oct last year, and as a result haven't had to take ANY sick day so far (darn, I'm wasting Google's policy of giving unlimited sick days...!!!). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] conditional expressions - add parens?
On Mar 6, 2006, at 9:17 AM, Jim Jewett wrote: ... I think that adding parentheses would help, by at least signalling that the logic is longer than just the next (single) expression. level = (0 if absolute_import in self.futures else -1) +1 (just because I can't give it +3.1415926...!!!). *Mandatory* parentheses make this form MUCH more readable. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Translating docs
On Feb 25, 2006, at 4:43 PM, [EMAIL PROTECTED] wrote: Zitat von Facundo Batista [EMAIL PROTECTED]: The question is, it's ok to use a third party system for this initiative? Or you (we) prefer to host it in-house? Someone alredy thought of this? I thought about it at one time, and I think the doc strings can be translated very well using gettext-based procedures; I once submitted a POT file to the translation project: http://www.iro.umontreal.ca/translation/registry.cgi?domain=python Translating the library reference as such is more difficult, because it can't be translated in small chunks very well. Some group of French translators once translated everything for 1.5.2, and that translation never got updated. A similar situation applies to Italy -- a lot of stuff is translated at http://www.python.it/doc/Python-Docs/html/ (the C-API and Extending and Embedding aren't translated, though), but it's 2.3.4- vintage docs. There's no real mechanism or process to ensure updates. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OT: T-Shirts
On Feb 23, 2006, at 6:12 PM, Facundo Batista wrote: Python Argentina finally have T-Shirts (you can see a photo here: http://www.taniquetil.com.ar/plog/post/1/161). Why this mail to python-dev? Because the group decided to give some, as a present, to some outstanding members of Python: Guido van Rossum Alex Martelli many other worthies snipped T-shirts? I'm an absolute fan of T-shirts...!-) The point is that I don't know some of you, so please grab my shoulder here in PyCon. And if you're not coming to the conference but somebody can carry it to you, just let me know. Anna can bring mine!!! And if you want to buy one, I brought some, only USD 12, ;). Anna, please buy one for yourself before they run out -- they're cool, and this way we can go around as the AR (Anna Ravenscroft, of course!) Python Twins...!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 22, 2006, at 7:21 AM, Raymond Hettinger wrote: ... I'm somewhat happy with the patch as it stands now. The only part that needs serious rethinking is putting on_missing() in regular dicts. See my other email on that subject. What if we named it _on_missing? Hook methods intended only to be overridden in subclasses are sometimes spelled that way, and it removes the need to teach about it to beginners -- it looks private so we don't explain it at that point. My favorite example is Queue.Queue: I teach it (and in fact evangelize for it as the one sane way to do threading;-) in Python 101, *without* ever mentioning _get, _put etc -- THOSE I teach in Patterns with Python as the very bext example of the Gof4's classic Template Method design pattern. If dict had _on_missing I'd have another wonderful example to teach from! (I believe the Library Reference avoids teaching about _get, _put etc, too, though I haven't checked it for a while). TM is my favorite DP, so I'm biased in favor of Guido's design, and I think that by giving the hook method (not meant to be called, only overridden) a private name we're meeting enough of your and /F's concerns to let _on_missing remain. Its existence does simplify the implementation of defaultdict (and some other dict subclasses), and if the implementation is easy to explain, it may be a good idea, after all;-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 20, 2006, at 5:41 AM, Guido van Rossum wrote: ... Alternative A: add a new method to the dict type with the semantics of __getattr__ from the last proposal, using default_factory if not None (except on_missing is inlined). This avoids the discussion about broken invariants, but one could argue that it adds to an already overly broad API. Alternative B: provide a dict subclass that implements the __getattr__ semantics from the last proposal. It could be an unrelated type for all I care, but I do care about implementation inheritance since it should perform just as well as an unmodified dict object, and that's hard to do without sharing implementation (copying would be worse). Let's do both!...;-). Add a method X to dict as per A _and_ provide in collections a subclass of dict that sets __getattr__ to X and also takes the value of default_dict as the first mandatory argument to __init__. Yes, mapping is a fat interface, chock full of convenience methods, but that's what makes it OK to add another, when it's really convenient; and nearly nobody's been arguing against defaultdict, only about the details of its architecture, so the convenience of this X can be taken as established. As long as DictMixin changes accordingly, the downsides are small. Also having a collections.defaultdict as well as method X would be my preference, for even more convenience. From my POV, either or both of these additions would be an improvement wrt 2.4 (as would most of the other alternatives debated here), but I'm keen to have _some_ alternative get in, rather than all being blocked out of 2.5 by analysis paralysis. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 20, 2006, at 8:35 AM, Raymond Hettinger wrote: [GvR] I'm not convinced by the argument that __contains__ should always return True Me either. I cannot think of a more useless behavior or one more likely to have unexpected consequences. Besides, as Josiah pointed out, it is much easier for a subclass override to substitute always True return values than vice-versa. Agreed on all counts. I prefer this approach over subclassing. The mental load from an additional method is less than the load from a separate type (even a subclass). Also, avoidance of invariant issues is a big plus. Besides, if this allows setdefault() to be deprecated, it becomes an all-around win. I'd love to remove setdefault in 3.0 -- but I don't think it can be done before that: default_factory won't cover the occasional use cases where setdefault is called with different defaults at different locations, and, rare as those cases may be, any 2.* should not break any existing code that uses that approach. - Even if the default_factory were passed to the constructor, it still ought to be a writable attribute so it can be introspected and modified. A defaultdict that can't change its default factory after its creation is less useful. Right! My preference is to have default_factory not passed to the constructor, so we are left with just one way to do it. But that is a nit. No big deal either way, but I see passing the default factory to the ctor as the one obvious way to do it, so I'd rather have it (be it with a subclass or a classmethod-alternate constructor). I won't weep bitter tears if this drops out, though. - It would be unwise to have a default value that would be called if it was callable: what if I wanted the default to be a class instance that happens to have a __call__ method for unrelated reasons? Callability is an elusive propperty; APIs should not attempt to dynamically decide whether an argument is callable or not. That makes sense, though it seems over-the-top to need a zero- factory for a multiset. But int is a convenient zero-factory. An alternative is to have two possible attributes: d.default_factory = list or d.default_value = 0 with an exception being raised when both are defined (the test is done when the attribute is created, not when the lookup is performed). I see default_value as a way to get exactly the same beginner's error we already have with function defaults: a mutable object will not work as beginners expect, and we can confidently predict (based on the function defaults case) that python-list and python-help and python-tutor and a bazillion other venues will see an unending stream of confused beginners (in addition to those confused by mutable objects as default values for function arguments, but those can't be avoided). I presume you consider the one obvious way is to use default_value for immutables and default_factory for mutables, but based on a lot of experience teaching Python I feel certain that this won't be obvious to many, MANY users (and not just non-Dutch ones, either). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 20, 2006, at 12:33 PM, Guido van Rossum wrote: ... You don't need a new feature for that use case; d[k] = d.get(k, 0) + 1 is perfectly fine there and hard to improve upon. I see d[k]+=1 as a substantial improvement -- conceptually more direct, I've now seen one more k than I had seen before. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: defaultdict
On Feb 20, 2006, at 12:38 PM, Aahz wrote: ... Can you say, for the record (since nobody else seems to care), if d.getorset(key, func) would work in your use cases? Because I haven't been reading this thread all that closely, you'll have to remind me what this means. Roughly the same (save for method/function difference) as: def getorset(d, key, func): if key not in d: d[key] = func() return d[key] Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 20, 2006, at 3:04 PM, Brett Cannon wrote: ... - Yes and it should be the only constructor argument. This is my ... While #3 is my preferred solution as well, it does pose a Liskov violation if this is a direct dict subclass instead of storing a dict How so? Liskov's principle is (in her own words): If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T. How can this ever be broken by the mere presence of incompatible signatures for T's and S's ctors? I believe the principle, as stated above, was imperfectly stated, btw (it WAS preceded by something like the following substitution property, indicating that Liskov was groping towards a good formulation), but that's an aside -- the point is that the principle is about substitution of _objects_, i.e., _instances_ of the types S and T, not about substitution of the _types_ themselves for each other. Instances exist and are supposed to satisfy their invariants _after_ ctors are done executing; ctor's signatures don't matter. In Python, of course, you _could_ call type(o2)(...) and possibly get different behavior if that was changed into type(o1)(...) -- the curse of powerful introspection;-). But then, isn't it trivial to obtain cases in which the behavior is NOT unchanged? If it was always unchanged, what would be the point of ever subclassing?-) Say that o2 is an int and o1 is a bool -- just a print o2 already breaks the principle as stated (it's harder to get a simpler P than this...). Unless you have explicitly documented invariants (such as any 'print o' must emit 1+ digits followed by a newline for integers), you cannot say that some alleged subclass is breaking Liskov's property, in general. Mere change of behavior in the most general case cannot qualify, if method overriding is to be any use; such change IS traditionally allowed as long as preconditions are looser and postconditions are stricter; and I believe than in any real-world subclassing, with sufficient introspection you'll always find a violation E.g., a subtype IS allowed to add methods, by Liskov's specific example; but then, len(dir(o1)) cannot fail to be a higher number than len(dir(o2)), from which you can easily construct a P which changes behavior for any definition you care to choose. E.g., pick constant N as the len(dir(...)) for instances of type T, and say that MN is the len(dir(...)) for instances of S. Well, then, math.sqrt(N-len(dir(o2))) is well defined -- but change o2 into o1, and since N-M is 0, you'll get an exception. If you can give an introspection-free example showing how Liskov substitution would be broken by a mere change to incompatible signature in the ctor, I'll be grateful; but I don't think it can be done. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
On Feb 20, 2006, at 5:05 PM, Raymond Hettinger wrote: [Alex] I see d[k]+=1 as a substantial improvement -- conceptually more direct, I've now seen one more k than I had seen before. [Guido] 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. OK, sounds great to me. collections.defaultdict, then? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory Error the right error for coding cookie promise violation?
On Feb 21, 2006, at 6:53 AM, Bengt Richter 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 stdin, line 1, in ? MemoryError Definitely looks like a bug, please open a bug report for it. Thanks, Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator(s) module
On Feb 18, 2006, at 12:38 AM, Georg Brandl wrote: Guido van Rossum wrote: WFM. Patch anyone? Done. http://python.org/sf/1434038 I reviewed the patch and added a comment on it, but since the point may be controversial I had better air it here for discussion: in 2.4, property(fset=acallable) does work (maybe silly, but it does make a write-only property) -- with the patch as given, it would stop working (due to attempts to get __doc__ from the None value of fget); I think we should ensure it keeps working (and add a unit test to that effect). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal: defaultdict
On 2/16/06, Guido van Rossum [EMAIL PROTECTED] wrote: A bunch of Googlers were discussing the best way of doing the ... Wow, what a great discussion! As you'll recall, I had also mentioned the callable factory as a live possibility, and there seems to be a strong sentiment in favor of that; not really a weakness case for HOFs, as you feared it might be during the lunchtime discussion. Out of all I've read here, I like the idea of having a collections.autodict (a much nicer name than defaultdict, a better collocation for 2.5 than the builtins). One point I think nobody has made is that whenever reasonably possible the setting of a callback (the callable factory here) should include *a and **k to use when calling back. So, for example: ad = collections.autodict(copy.copy, whatever) would easily cover the use case of Google's DefaultDict (yes, partial would also cover this use case, but having *a and **k is usefully more general). If you're convinced copy.copy is an overwhelmingly popular use case (I'm not, personally), then this specific idiom might also be summarized in a classmethod, a la ad = collections.autodict.by_copy(whatever) This way, all autodicts would start out empty (and be filled by update if needed). An alternative would be to have autodict's ctor have the same signature as dict's, with a separate .set_initial method to pass the factory (and *a, **k) -- this way an autodict might start out populated, but would always start with some default factory, such as lambda:None I guess. I think the first alternative (autodict always starts empty, but with a specifically chosen factory [including *a, **k]) is more useful. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The decorator(s) module
On 2/17/06, Georg Brandl [EMAIL PROTECTED] wrote: Ian Bicking wrote: Unfortunately, a @property decorator is impossible... It already works! But only if you want a read-only property. Which is actually about 50%+ of the properties I create. So the status quo is not really that bad. I have abused it this way too and felt bad every time. Kind of like keeping your hat on in the church. :) It's not ideal, because the resulting r-o property has no docstring: class ex(object): ... @property ... def amp(self): ... ''' a nice docstring ''' ... return 23 ... ex.amp.__doc__ class xe(object): ... def amp(self): return 23 ... amp=property(amp, doc='whatever!') ... xe.amp.__doc__ 'whatever!' Maybe we could fix that by having property(getfunc) use getfunc.__doc__ as the __doc__ of the resulting property object (easily overridable in more normal property usage by the doc= argument, which, I feel, should almost invariably be there). Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str object going in Py3K
On Feb 15, 2006, at 9:51 AM, Barry Warsaw wrote: On Wed, 2006-02-15 at 09:17 -0800, Guido van Rossum wrote: Regarding open vs. opentext, I'm still not sure. I don't want to generalize from the openbytes precedent to openstr or openunicode (especially since the former is wrong in 2.x and the latter is wrong in 3.0). I'm tempting to hold out for open() since it's most compatible. If we go with two functions, I'd much rather hang them off of the file type object then add two new builtins. I really do think file.bytes() and file.text() (a.k.a. open.bytes() and open.text()) is better than opentext() or openbytes(). I agree, or, MAL's idea of bytes.open() and unicode.open() is also good. My fondest dream is that we do NOT have an 'open' builtin which has proven to be very error-prone when used in Windows by newbies (as evidenced by beginner errors as seen on c.l.py, the python-help lists, and other venues) -- defaulting 'open' to text is errorprone, defaulting it to binary doesn't seem the greatest idea either, principle when in doubt, resist the temptation to guess strongly suggests not having 'open' as a built-in at all. (And namemangling into openthis and openthat seems less Pythonic to me than exploiting namespaces by making structured names, either this.open and that.open or open.this and open.that). IOW, I entirely agree with Barry and Marc Andre. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str object going in Py3K
On 2/14/06, Just van Rossum [EMAIL PROTECTED] wrote: ... Maybe it's even better to use opentext() AND openbinary(), and deprecate plain open(). We could even introduce them at the same time as bytes() (and leave the open() deprecation for 3.0). What about shorter names, such as 'text' instead of 'opentext' and 'data' instead of 'openbinary'? By eschewing the 'open' prefix we might make it easy to eventually migrate off it. Maybe text and data could be two subclasses of file, with file remaining initially as it is (and perhaps becoming an abstract-only baseclass at the time 'open' is deprecated). In real life, people do all the time use 'open' inappropriately (on non-text files on Windows): one of the most frequent tasks on python-help has to do with diagnosing that this is what happened and suggest the addition of an explicit 'rb' or 'wb' argument. This unending chore, in particular, makes me very wary of forever keeping open to mean open this _text_ file. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/13/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... I don't like to add a built-in index() at this point; mostly because of Occam's razor (we haven't found a need). I thought you had agreed, back when I had said that __index__ should also be made easily available to implementors of Python-coded classes implementing sequences, more elegantly than by demanding that they code x.__index__() [I can't think offhand of any other special-named method that you HAVE to call directly -- there's always some syntax or functionality in the standard library to call it more elegantly on your behalf]. This doesn't neessarily argue that index should be in the built-ins module, of course, but I thought there was a sentiment towards having it in either the operator or math modules. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 351
On Feb 10, 2006, at 1:05 PM, Raymond Hettinger wrote: [Guido van Rossum] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? It has at least one anti-champion. I think it is a horrible idea and would like to see it rejected in a way that brings finality. If needed, I can elaborate in a separate thread. Could you please do that? I'd like to understand all of your objections. Thanks! Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] release plan for 2.5 ?
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: October would seem to me to be just about right. I don't see that one month either way should make any big difference, though. ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. If I could have a definitive frozen list of features by the first week of April at the latest, that could make it (as a 2.5 preview) into the 2nd edition of Python in a Nutshell. But since alphas are not feature-frozen, it wouldn't make much of a difference to me, I think. Other PEPs I'd like comment on: PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't look like it'll cause any problems. It does look great, and by whatever name I support it most heartily. Do, however, notice that it's yet another specialpurpose adaptation protocol and that such specific restricted solutions to the general problem, with all of their issues, will just keep piling up forever (and need legacy support ditto) until and unless your temperature wrt 246 (or any variation thereof) should change. PEP 355 (path module): I still haven't reviewed this, because I'm -0 on adding what appears to me duplicate functionality. But if there's a I feel definitely -0 towards it too. PEP 315 - do while. A simple enough syntax proposal, albeit one introducing a new keyword (which I'm fine with). I kind of like it but it doesn't strike me as super important -- if we put this off until Py3k I'd be fine with that too. Opinions? Champions? Another -0 from me. I suggest we shelve it for now and revisit in 3k (maybe PEPs in that state, not in any 2.* but revisit for 3.0, need a special status value). PEP 246 - adaptation. I'm still as lukewarm as ever; it needs interfaces, promises to cause a paradigm shift, and the global map worries me. Doesn't _need_ interfaces as a concept -- any unique markers as protocol names would do, even strings, although obviously the stronger the markers the better (classes/types for example would be just perfect). It was written on the assumption of interfaces just because they were being proposed just before it. The key paradigm shift is to offer a way to unify what's already being widely done, in haphazard and dispersed manners. And I'll be quite happy to rewrite it in terms of a more nuanced hierarchy of maps (e.g. builtin / per-module / lexically nested, or whatever) if that's what it takes to warm you to it -- I just think it would be over-engineering it, since in practice the global-on-all-modules map would cover by far most usage (both for blessed protocols that come with Python, and for the use of third party adapting framework A to consume stuff that framework B produces, global is the natural residence; other uses are far less important. PEP 323 - copyable iterators. Seems stalled. Alex, do you care? Sure, I'd like to make this happen, particularly since Raymond appears to have already done the hard part. What would you like to see happening to bless it for 2.5? PEP 332 - byte vectors. Looks incomplete. Put off until 2.6? Ditto -- I'd like at least SOME of it to be in 2.5. What needs to happen for that? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for adding an sq_index slot so that any object, a or b, can be used in X[a:b] notation
On 2/9/06, Travis E. Oliphant [EMAIL PROTECTED] wrote: ... The patch adds a new API function int PyObject_AsIndex(obj). This was not specifically in the PEP but probably should be. The name could also be PyNumber_AsIndex(obj) but I was following the nb_nonzero slot example to help write the code. Shouldn't that new API function (whatever its name) also be somehow exposed for easy access from Python code? I realize new builtins are unpopular, so a builtin 'asindex' might not be appropriate, but perhaps operator.asindex might be. My main point is that I don't think we want every Python-coded sequence to have to call x.__index__() instead. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] threadsafe patch for asynchat
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote: ... what other reactive socket framework is there that would fit well into the standard library ? is twisted really simple enough ? Twisted is wonderful, powerful, rich, and very large. Perhaps a small subset could be carefully extracted that (given suitable volunteers to maintain it in the future) might fit in the standard library, but [a] that extraction is not going to be a simple or fast job, and [b] I suspect that the minimum sensible subset would still be much larger (and richer / more powerful) than asyncore. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 2/6/06, Donovan Baarda [EMAIL PROTECTED] wrote:
yeah... the problem is differentiating the empty set from an empty dict.
The only alternative that occured to me was the not-so-nice and
not-backwards-compatible {:} for an empty dict and {} for an empty
set.
How about spelling the empty set as ``set()''? Wouldn't that solve the
ambiguity and the backwards compatibility nicely?
And of course, thanks to the time machine, it has always worked that way:
hesperos:~$ python2.4
Python 2.4.1 (#1, Apr 21 2005, 11:14:17)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
set()
set([])
just like dict(), tuple(), list(), str(), int(), float(), bool(),
complex() -- each type, called without args, returns an instance F of
that type such that bool(F) is False holds (meaning len(F)==0 for
container types, F==0 for number types).
Alex
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
On 2/6/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... What we should do in 3.0 is not entirely clear to me. It would be nice if there was only a single type (named 'int', of course) with two run-time representations, one similar to the current int and one similar to the current long. But that's not so easy, and somewhat contrary to the philosophy that differences in (C-level) representation are best distinguisghed by looking at the type of an object. The next most likely solution is to make long a subclass of int, or perhaps to make int an abstract base class with two subclasses, short and long. Essentially, you need to decide: does type(x) mostly refer to the protocol that x respects (interface plus semantics and pragmatics), or to the underlying implementation? If the latter, as your observation about the philosophy suggests, then it would NOT be nice if int was an exception wrt other types. If int is to be a concrete type, then I'd MUCH rather it didn't get subclassed, for all sorts of both pratical and principled reasons. So, to me, the best solution would be the abstract base class with concrete implementation subclasses. Besides being usable for isinstance checks, like basestring, it should also work as a factory when called, returning an instance of the appropriate concrete subclass. AND it would let me have (part of) what I was pining for a while ago -- an abstract base class that type gmpy.mpz can subclass to assert I _am_ an integer type!, so lists will accept mpz instances as indices, etc etc. Now consider how nice it would be, on occasion, to be able to operate on an integer that's guaranteed to be 8, 16, 32, or 64 bits, to ensured the desired shifting/masking behavior for certain kinds of low-level programming; and also on one that's unsigned, in each of these sizes. Python could have a module offering signed8, unsigned16, and so forth (all combinations of size and signedness supported by the underlying C compiler), all subclassing the abstract int, and guarantee much happiness to people who are, for example, writing a Python prototype of code that's going to become C or assembly... Similarly, it would help a slightly different kind of prototyping a lot if another Python module could offer 32-bit, 64-bit, 80-bit and 128-bit floating point types (if supported by the underlying C compiler) -- all subclassing an ABSTRACT 'float'; the concrete implementation that one gets by calling float or using a float literal would also subclass it... and so would the decimal type (why not? it's floating point -- 'float' doesn't mean 'BINARY fp';-). And I'd be happy, because gmpy.mpf could also subclass the abstract float! And then finally we could have an abstract superclass 'number', whose subclasses are the abstract int and the abstract float (dunno 'bout complex, I'd be happy either way), and Python's typesystem would finally start being nice and cleanly organized instead of grand-prarie-level flat ...!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] math.areclose ...?
On 2/6/06, Aahz [EMAIL PROTECTED] wrote: ... def areclose(x, y, relative_err = 1.e-5, absolute_err=1.e-8): diff = abs(x - y) ave = (abs(x) + abs(y))/2 return diff absolute_err or diff/ave relative_err Also, separating the two terms with 'or' rather than '+' makes the two error terms mean more what they are named. The '+' mixes the two effects and even though the result is basically the same, it makes it difficult to explain when the test will be true. Yes, that's a big help. I was a bit concerned that this would have no utility for numbers with large magnitude. Alex, given your focus on Python readability, I'm a bit surprised you didn't write this to start with! As I said, I was just copying the definition in Numeric, which is well-tried by long use. Besides, this clear expression could present problems, such as possible overflows or divisions by zero when ave is 0 or very small; much as I care about readability, I care about correctness even more. Once it comes to readability, I prefer Numeric's choice to call the two terms tolerances, rather than (as here) errors; maybe that depends on my roots being in engineering, where an error means a mistake (like it does in real life), while tolerance's a good and useful thing to have (ditto), rather than some scientific discipline where terms carry different nuances. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] math.areclose ...?
When teaching some programming to total newbies, a common frustration is how to explain why a==b is False when a and b are floats computed by different routes which ``should'' give the same results (if arithmetic had infinite precision). Decimals can help, but another approach I've found useful is embodied in Numeric.allclose(a,b) -- which returns True if all items of the arrays are ``close'' (equal to within certain absolute and relative tolerances): (1.0/3.0)==(0.1/0.3) False Numeric.allclose(1.0/3.0, 0.1/0.3) 1 But pulling in the whole of Numeric just to have that one handy function is often overkill. So I was wondering if module math (and perhaps by symmetry module cmath, too) shouldn't grow a function 'areclose' (calling it just 'close' seems likely to engender confusion, since 'close' is more often used as a verb than as an adjective; maybe some other name would work better, e.g. 'almost_equal') taking two float arguments and optional tolerances and using roughly the same specs as Numeric, e.g.: def areclose(x,y,rtol=1.e-5,atol=1.e-8): return abs(x-y)atol+rtol*abs(y) What do y'all think...? Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
