Re: [Python-Dev] syntactic support for sets
On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote: Donovan Baarda [EMAIL PROTECTED] wrote: [...] Nuff was a fairy... though I guess it depends on where you draw the line; should [1,2,3] be list(1,2,3)? Who is Nuff? fairynuff... :-) Along the lines of not every x line function should be a builtin, not every builtin should have syntax. I think that sets have particular uses, but I don't believe those uses are sufficiently varied enough to warrant the creation of a syntax. I suggest that people take a walk through their code. How often do you use other sequence and/or mapping types? How many lists, tuples and dicts are there? How many sets? Ok, now how many set literals? The absence of sets in early Python, the requirement to import sets when they first appeared, and the lack of a set syntax now all mean that people tend to avoid using sets and resort to lists, tuples, and dicts of None instead, even though they really want a set. Anywhere you see if value in sequence:, they probably mean sequence is a set, and this code would run much faster if it really was, and might even avoid potential bugs because it would prevent duplicates... -- Donovan Baarda [EMAIL PROTECTED] http://minkirri.apana.org.au/~abo/ ___ 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 Fri, 2006-02-03 at 20:02 +0100, Martin v. Löwis wrote:
Donovan Baarda wrote:
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
There might be many reasons; one obvious reason is that you can't spell
the empty set that way.
Hmm... how about {,}, which is the same trick tuples use for the empty
tuple?
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
___
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 Mon, 6 Feb 2006 09:05:01 +0100, Thomas Wouters [EMAIL PROTECTED] wrote: On Mon, Feb 06, 2006 at 05:33:57AM +, Bengt Richter wrote: Perhaps I missed a py3k assumption in this thread (where I see in the PEP that Remove distinction between int and long types is core item number one)? http://www.python.org/peps/pep-0237.html -- an ungoing process, not a Py3K-eventual one. Thanks, I noticed. Hence my question following what you quote: Is PEP 237 phase C to be implemented sooner than py3k, making isinstance(something, int) a transparently distinction-hiding alias for isinstance(something, integer), or outright illegal? IOW, will isinstance(something, int) be _guaranteed_ to be a bug, thus requiring code change? If so, when? Sorry that my paragraph-packing habit tends to bury things. I'll have to work on that ;-/ Regards, Bengt Richter ___ 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 Mon, 2006-02-06 at 15:36 +0100, Ronald Oussoren wrote:
On Monday, February 06, 2006, at 03:12PM, Donovan Baarda [EMAIL PROTECTED]
wrote:
On Fri, 2006-02-03 at 20:02 +0100, Martin v. Löwis wrote:
Donovan Baarda wrote:
Before set() the standard way to do them was to use dicts with None
Values... to me the {1,2,3} syntax would have been a logical extension
of the a set is a dict with no values, only keys mindset. I don't know
why it wasn't done this way in the first place, though I missed the
arguments where it was rejected.
There might be many reasons; one obvious reason is that you can't spell
the empty set that way.
Hmm... how about {,}, which is the same trick tuples use for the empty
tuple?
Isn't () the empty tuple? I guess you're confusing this with a single element
tuple: (1,) instead of (1) (well actually it is 1,)
Yeah, sorry.. nasty brainfart...
BTW. I don't like your proposal for spelling the empty set as {,} because
that is entirely non-obvious. If {1,2,3} where a valid way to spell a set
literal, I'd expect {} for the empty set.
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.
--
Donovan Baarda [EMAIL PROTECTED]
http://minkirri.apana.org.au/~abo/
___
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, Bengt Richter [EMAIL PROTECTED] wrote: Is PEP 237 phase C to be implemented sooner than py3k, making isinstance(something, int) a transparently distinction-hiding alias for isinstance(something, integer), or outright illegal? IOW, will isinstance(something, int) be _guaranteed_ to be a bug, thus requiring code change? If so, when? Probably not before Python 3.0. Until then, int and long will be distinct types for backwards compatibilty reasons. But we want as much code as possible to treat longs the same as ints, hence the party line that (barring attenuating circumstances :-) isinstance(x, int) is a bug if the code doesn't also have a similar case for long. If you find standard library code (in Python *or* C!) that treats int preferentially, please submit a patch or bug. 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. -- --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/archive%40mail-archive.com
Re: [Python-Dev] syntactic support for sets
Donovan Baarda [EMAIL PROTECTED] wrote: On Fri, 2006-02-03 at 11:56 -0800, Josiah Carlson wrote: Along the lines of not every x line function should be a builtin, not every builtin should have syntax. I think that sets have particular uses, but I don't believe those uses are sufficiently varied enough to warrant the creation of a syntax. I suggest that people take a walk through their code. How often do you use other sequence and/or mapping types? How many lists, tuples and dicts are there? How many sets? Ok, now how many set literals? The absence of sets in early Python, the requirement to import sets when they first appeared, and the lack of a set syntax now all mean that people tend to avoid using sets and resort to lists, tuples, and dicts of None instead, even though they really want a set. Anywhere you see if value in sequence:, they probably mean sequence is a set, and this code would run much faster if it really was, and might even avoid potential bugs because it would prevent duplicates... Maybe they mean set, maybe they don't. 'if obj in seq' is used for various reasons. A quick check of the Python standard library shows that some of the uses of 'if obj in tuple_literal' could certainly be converted into sets, but that ignores the performance impact of using sets instead of short tuples (where short, if I remember correctly, is a length of 3, check the python-dev archives), as well as the module-level contant creation that occurs with tuples. There was probably a good reason why such a thing hasn't happened with lists and dicts (according to my Python 2.4 installation), and why it may not happen with sets. A nontrivial number of other 'if obj in seq' instances actually need dictionaries, the test is for some sort of data handler or headers with a particular name. - Josiah ___ 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 Mon, Feb 06, 2006, Chris or Leslie Smith wrote: Aahz: Alex: || def areclose(x,y,rtol=1.e-5,atol=1.e-8): || return abs(x-y)atol+rtol*abs(y) | | Looks interesting. I don't quite understand what atol/rtol are, | though. Does it help to spell it like this? 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! -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ 19. A language that doesn't affect the way you think about programming, is not worth knowing. --Alan Perlis ___ 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] Let's just *keep* lambda
After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. +1. This would remove my strongest objection to the current Python 3000 PEP. Now, let's improve lambda... :-). Bill ___ 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
Re: [Python-Dev] Let's just *keep* lambda
Steven Bethard wrote: Guido van Rossum wrote: After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. +1 for keeping the functionality, especially given list and generator expressions being compound lambda expressions in a sense. Removing anonymous functions would break a nice symmetry there. .. _alternatives: http://wiki.python.org/moin/AlternateLambdaSyntax Of those, I like the for syntax without parens around the arguments best: (x*y + z for x, y, z). Parentheses around the whole expression should be optional in the same cases that allow for omitting parentheses around generator expressions. It fits perfectly with the way generator expression syntax relates to generator function definitions, and re-using the for keyword keeps the zoo of reserved words small. Just my 2 cents and all that... -- Thomas ___ 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 ...?
[Chris Smith] Does it help to spell it like this? 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 There is a certain beauty and clarity to this presentation; however, it is problematic numerically: * the division by either absolute_err and relative_err can overflow or trigger a ZeroDivisionError * the 'or' part of the expression can introduce an unnecessary discontinuity in the first derivative. The original Numeric definition is likely to be better for people who know what they're doing; however, I still question whether it is an appropriate remedy for the beginner issue of why 1.1 + 1.1 + 1.1 doesn't equal 3.3. Raymond ___ 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 ...?
2006/2/6, Raymond Hettinger [EMAIL PROTECTED]:
The original Numeric definition is likely to be better for people who know
what they're doing; however, I still question whether it is an appropriate
remedy for the beginner issue
of why 1.1 + 1.1 + 1.1 doesn't equal 3.3.
Beginners won't know about math.areclose anyway (and if they will,
they won't use it, thinking why bother?), and having a standard,
well-behaved and *correct* version of a useful function can't hurt.
--
{ Marek Baczyński :: UIN 57114871 :: GG 161671 :: JID [EMAIL PROTECTED] }
{ http://www.vlo.ids.gda.pl/ | imbaczek at poczta fm | http://www.promode.org }
.. .. .. .. ... ... .. evolve or face extinction .. ... ... .. .. .. ..
___
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 ...?
Alex Martelli wrote: 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. It looks like the definition from Numeric measures relative error while the above measure relative deviation. I'm not sure which one would be desirable or if they are interchangeable. I was looking up relative error to try and understand the above at the following site. http://mathforum.org/library/drmath/view/65797.html As far as beginner vs advanced users are concerned I think that is a matter of documentation especially when intermediate users are concerned which I believe are the majority. Possibly something like the following would be suitable... ? The absolute error is the absolute value of the difference between the accepted value and the measurement. Absolute error = abs( Observed - Accepted value ) The Relative err is the percentage of absolute err relative to the accepted value. Absolute error Relative error = -- x 100% Accepted value def isclose(observed, accepted, abs_err, rel_err): Determine if the accuracy of a observed value is close to an accepted value diff = abs(observed, accepted) if diff abs_err: return True try: return 100 * abs_diff / accepted rel_err except ZeroDivisionError: pass return False Cheers, Ron Adam ___ 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] Weekly Python Patch/Bug Summary
Patch / Bug Summary ___ Patches : 391 open ( +0) / 3038 closed (+10) / 3429 total (+10) Bugs: 915 open ( +9) / 5540 closed (+21) / 6455 total (+30) RFE : 209 open ( +2) / 197 closed ( +0) / 406 total ( +2) New / Reopened Patches __ difflib exceeding recursion limit (2006-01-24) CLOSED http://python.org/sf/1413711 opened by Gustavo Niemeyer Patch for bug #1380970 (2006-01-25) http://python.org/sf/1414934 opened by Collin Winter Clairify docs on reference stealing (2006-01-26) http://python.org/sf/1415507 opened by Collin Winter optparse enable_interspersed_args disable_interspersed_args (2006-01-26) http://python.org/sf/1415508 opened by Rocky Bernstein Configure patch for Mac OS X 10.3 (2006-01-27) http://python.org/sf/1416559 opened by Ronald Oussoren have SimpleHTTPServer return last-modified headers (2006-01-28) http://python.org/sf/1417555 opened by Aaron Swartz Fix be be documentation typo in lang ref (2006-02-01) CLOSED http://python.org/sf/1421726 opened by Wummel Changes to nis module to support multiple NIS domains (2006-02-02) CLOSED http://python.org/sf/1422385 opened by Ben Bell Patches Closed __ difflib exceeding recursion limit (2006-01-24) http://python.org/sf/1413711 closed by niemeyer fix bsddb test associate problems w/bsddb 4.1 (2006-01-16) http://python.org/sf/1407992 closed by greg Patch f. bug 495682 cannot handle http_proxy with user:pass@ (2005-11-05) http://python.org/sf/1349118 closed by loewis bsddb3 build problems on FreeBSD (2.4 + 2.5) (2005-02-22) http://python.org/sf/1146231 closed by greg Add support for db 4.3 (2004-11-23) http://python.org/sf/1071911 closed by nnorwitz zipfile: use correct system type on unixy systems (2006-01-23) http://python.org/sf/1412872 closed by loewis Fill out the functional module (2006-01-22) http://python.org/sf/1412451 closed by rhettinger Fix be be documentation typo in lang ref (2006-02-01) http://python.org/sf/1421726 closed by effbot Changes to nis module to support multiple NIS domains (2006-02-02) http://python.org/sf/1422385 closed by loewis anonymous mmap (2006-01-16) http://python.org/sf/1407135 closed by nnorwitz New / Reopened Bugs ___ Popenhangs with latest Cygwin update (2006-01-23) CLOSED http://python.org/sf/1413378 opened by Eric McRae Popened file object close hangs in latest Cygwin update (2006-01-23) http://python.org/sf/1413379 opened by Eric McRae zipfile: inserting some filenames produces corrupt .zips (2006-01-24) http://python.org/sf/1413790 opened by Grant Olson email.Utils.py: UnicodeError in RFC2322 header (2006-01-25) http://python.org/sf/1414018 opened by A. Sagawa Can only install 1 of each version of Python on Windows (2006-01-25) CLOSED http://python.org/sf/1414612 opened by Max M Rasmussen Underspecified behaviour of string.split/rsplit (2006-01-25) http://python.org/sf/1414673 opened by Collin Winter inconsistency in help(set) (2006-01-25) http://python.org/sf/1414697 opened by Gregory Petrosyan Typo in online documentation - 6.8.3.6 Replacing popen2.* (2006-01-26) CLOSED http://python.org/sf/1415455 opened by Phil Wright Inconsistency between StringIO and cStringIO (2006-01-27) http://python.org/sf/1416477 opened by Michael Kerrin Problem with SOAPpy on 64-bit systems (2006-01-27) CLOSED http://python.org/sf/1416544 opened by Gustavo J. A. M. Carneiro SimpleHTTPServer doesn't return last-modified headers (2006-01-28) http://python.org/sf/1417554 opened by Aaron Swartz EditorWindow demo causes attr-error (2006-01-29) http://python.org/sf/1417598 opened by snowman float/atof have become locale aware (2006-01-29) http://python.org/sf/1417699 opened by Bernhard Herzog PyRun_SimpleString won't parse \\x (2006-01-30) CLOSED http://python.org/sf/1418374 opened by gnupun PyImport_AppendInittab stores pointer to parameter (2006-01-31) http://python.org/sf/1419652 opened by coder_5 class dictionary shortcircuits __getattr__ (2006-01-31) http://python.org/sf/1419989 opened by Shaun Cutts IMPORT PROBLEM: Local submodule shadows global module (2006-02-01) http://python.org/sf/1421513 opened by Jens Engel [win32] stderr atty encoding not set (2006-02-01) http://python.org/sf/1421664 opened by Snaury http response dictionary incomplete (2006-02-01) http://python.org/sf/1421696 opened by Jim Jewett CVS (not SVN) mentioned in Python FAQ (2006-02-01) CLOSED http://python.org/sf/1421811 opened by Gregory Petrosyan 2.4.1 mentioned in Python FAQ as most stable version (2006-02-01) CLOSED http://python.org/sf/1421814 opened by Gregory Petrosyan Inconsistency in Programming FAQ (2006-02-01)
[Python-Dev] threadsafe patch for asynchat
Does anyone have any comments about applying the following patch to asynchat? It should not affect the behavior of the module in any way for those who do not want to use the feature provided by the patch. The point of the patch is to make it easy to use asynchat in a multithreaded application. Maybe I am missing something, and the patch really doesn't make it threadsafe? Any comments would be appreciated. Also, if it looks good to everyone, feel free to use it. ---BEGIN PATCH-- --- asynchat.pyFri Oct 15 03:03:16 2004 +++ asynchat.py.newSun Feb 05 22:05:42 2006 @@ -59,10 +59,11 @@ ac_in_buffer_size = 4096 ac_out_buffer_size = 4096 -def __init__ (self, conn=None): +def __init__ (self, conn=None, running_in_thread=False): self.ac_in_buffer = '' self.ac_out_buffer = '' self.producer_fifo = fifo() +self.running_in_thread = runnning_in_thread asyncore.dispatcher.__init__ (self, conn) def collect_incoming_data(self, data): @@ -157,7 +158,9 @@ def push (self, data): self.producer_fifo.push (simple_producer (data)) -self.initiate_send() +# only initiate a send if not running in a threaded environment, since +# initiate_send() is not threadsafe. +if not self.running_in_thread: self.initiate_send() def push_with_producer (self, producer): self.producer_fifo.push (producer) ---END PATCH-- -Mark ___ 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] Let's just *keep* lambda
Guido van Rossum wrote: After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. The inline anonymous `def` isn't as ugly/problematic as the block (block anonymous def) version, and could probably work better than lambda, I think (a bit more verbose, but at least it doesn't feel like a castrated function definition, is more coherent with the existing function definition syntax, and accepts more than a single statement... well that last part probably isn't a pro arguments...). Couldn't it be enabled (as an inline construct only) to replace the current lambda? ___ 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] Let's just *keep* lambda
On 2/5/06, Guido van Rossum [EMAIL PROTECTED] wrote: After so many attempts to come up with an alternative for lambda, perhaps we should admit defeat. I've not had the time to follow the most recent rounds, but I propose that we keep lambda, so as to stop wasting everybody's talent and time on an impossible quest. I have been thinking about this, and I have to say I am a little disappointed (-0 disappointed, not -1 disappointed). I honestly bought the argument for removing lambda. And I think that a deferred object would help with one of lambda's biggest uses and made its loss totally reasonable. But I know that everyone and their email client is against me on this one, so I am not going to really try to tear into this. But I do think that lambda needs a renaming. Speaking as someone who still forgets that Python's lambda is not the same as those found in functional languages, I would much rather have it named 'expr' or 'expression' or something that is more inline with its abilities then with a name taken for CS historical reasons. This ain't for father's lambda and thus shouldn't be named so. Then again, Guido did say he should, not that he did admit defeat. =) -Brett ___ 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
Mark Edgington wrote: Does anyone have any comments about applying the following patch to asynchat? That patch looks wrong. What does it mean to run in a thread? All code runs in a thread, all the time: sometime, that thread is the main thread. Furthermore, I can't see any presumed thread-unsafety in asynchat. Sure, there is a lot of member variables in asynchat which aren't specifically protected against mutual access from different threads. So you shouldn't be accessing the same async_chat object from multiple threads. I cannot see why using a creating and using an async_chat object in a thread that is not the main thread could cause any problems. I also cannot see how this patch could have significant effect on asyn_chat's behaviour when used in multiple threads. 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/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
Brett Cannon wrote: But I know that everyone and their email client is against me on this one, so I am not going to really try to tear into this. But I do think that lambda needs a renaming. Speaking as someone who still forgets that Python's lambda is not the same as those found in functional languages Can you elaborate on that point? I feel that Python's lambda is exactly the same as the one in Lisp. Sure, the Lisp lambda supports multiple sequential expressions (the progn feature), but I understand that this is just an extension (although one that has been around several decades). Of course, Python's expressions are much more limited as Lisp's (where you really can have macros and special forms in as the expression in a lambda), but the lambda construct itself seems to be the very same one. 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/archive%40mail-archive.com
Re: [Python-Dev] Let's just *keep* lambda
On 2/7/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Brett Cannon wrote: But I know that everyone and their email client is against me on this one, so I am not going to really try to tear into this. But I do think that lambda needs a renaming. Speaking as someone who still forgets that Python's lambda is not the same as those found in functional languages Can you elaborate on that point? I feel that Python's lambda is exactly the same as the one in Lisp. Sure, the Lisp lambda supports multiple sequential expressions (the progn feature), but I understand that this is just an extension (although one that has been around several decades). Of course, Python's expressions are much more limited as Lisp's (where you really can have macros and special forms in as the expression in a lambda), but the lambda construct itself seems to be the very same one. If we phrase it somewhat differently, we can see that lambdas are different in Python and Lisp, in a very practical way. First: Everything in Lisp is an expression. There's no statement, in Lisp, that isn't also an expression. Lambdas in Lisp can contain arbitrary expressions; therefore you can put any language construct inside a lambda. In Python, you cannot put any language construct inside a lambda. Python's and Lisp's lambdas are effectively totally different. +1 on keeping Lambda, +1 on making it more useful. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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
