Re: [Python-Dev] RFC: readproperty

[Jim Fulton]

Guido van Rossum wrote:
> On 9/28/05, Jim Fulton <[EMAIL PROTECTED]> wrote:
> 
...
> I think we need to be real careful with chosing a name -- in Jim's
> example, *anyone* could assign to Spam().eggs to override the value.
> The name "readproperty" is too close to "readonlyproperty",

In fact, property creates read-only properties for new-style classes.
(I hadn't realized, until reading this thread, that for classic
classes, you could still set the attribute.)

 > but
> read-only it ain't! "Lazy" also doesn't really describe what's going
> on.

I agree.

> I believe some folks use a concept of "memo functions" which resemble
> this proposal except the notation is different: IIRC a memo function
> is always invoked as a function, but stores its result in a private
> instance variable, which it returns upon subsequent calls. This is a
> common pattern. Jim's proposal differs because the access looks like
> an attribute, not a method call. Still, perhaps memoproperty would be
> a possible name.
> 
> Another way to look at the naming problem is to recognize that the
> provided function really computes a default value if the attribute
> isn't already set. So perhaps defaultproperty?

Works for me.

Oleg Broytmann wrote:
 > On Wed, Sep 28, 2005 at 10:16:12AM -0400, Jim Fulton wrote:
 >
 >>   class readproperty(object):
 >
 > [skip]
 >
 >>I do this often enough
 >
 >
 >I use it since about 2000 often enough under the name CachedAttribute:
 >
 > http://cvs.sourceforge.net/viewcvs.py/ppa/qps/qUtils.py

Steven Bethard wrote:
 > Jim Fulton wrote:
 >
...
 > I've also needed behavior like this a few times, but I use a variant
 > of Scott David Daniel's recipe[1]:
 >
 > class _LazyAttribute(object):


Yup, the Zope 3 sources have something very similar:

http://svn.zope.org/Zope3/trunk/src/zope/cachedescriptors/property.py?view=markup

I actually think this does too much.  All it saves me, compared to what I 
proposed
is one assignment.  I'd rather make that assignment explicit.

Anyway, all I wanted with readproperty was a property that implemented only
__get__, as opposed to property, which implements __get__, __set__, and 
__delete__.

I'd be happy to call it readproprty or getproperty or defaulproperty or 
whatever. :)

I'd prefer that it's semantics stay fairly simple though.


Jim

-- 
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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 350: Codetags

[Micah Elliott]

Thanks to all who have read and/or provided feedback.  There have been
some great ideas and admonitions that hadn't crossed my mind.  I'll
paraphrase some of the responses for the sake of brevity; I don't mean
to misquote anyone.

Tom> ISO 8601 includes a week notation.

That's great.  Thanks for pointing it out; seems like it should be the
preferred week format.  I might also want to allow a simple W42 (say)
since it's so much shorter, and I'll consider myself generally in
trouble if I wrap around on the year for due items.

Terry> Shorter forms such as DO, FIX, DEF, DOC, etc. are better.

I like the short proposals, so I'll add, and possibly even canonize
them.  My proposed canons were based on popular use and also my taste.
I had originally wanted to state that only the canonical forms would
be supported and use of the synonyms should be deprecated.  That would
have simplified things a bit (human and tool parsing).  But based on
people's ideas about what is canonical, that would never have flown.
Instead, it seems useful to just list everything that's ever been used
as long as it *fits one of the categories*.  And the canon is mostly
arbitrary/unnecessary; we'd never settle that peacefully anyway.  The
main point is that official categorization enables construction of
productivity tools.

Terry> IDEXXX isn't vim/emacs.  Offer an x:"comment" field for a
Terry> completed item.

Bengt> Later a tool can strip this out to the devlog.txt or DONE
Bengt> file, when the tool sees an added progress line like
Bengt> # ---: woohoo, completed ;-) 

I wish we could rely on everyone to have/use cron.  These are both
great ideas.  I'd like to allow/have both.

Bengt> 7) A way of appending an incremental progress line to an existing code
Bengt> tag line, e.g.,
Bengt> # FIXME: This will take a while: rework foo and bar 
Bengt> # ...: test_foo for new foo works! 
Bengt> # ...: vacation 

Status updates?  Nice!!  Great syntax too.

Bengt> time, embedded in strings, scope, no DONE, same line as code...

Your pennies are gold!  Thanks!

Another thing that came to mind recently:  As with docstrings, the
first sentence of a multiline codetags should be a meaningful summary.
So for multiline codetags I'll suggest that the fist line be something
that could show up in say a manpage or a BUGFIX file.

Terry> Terminator <> is evil.  Whitespace is good.

Bruno> Or if the codetag is immediately followed by code it's
Bruno> terminated.

Yes, I'd actually forgotten that it is also not-equal!  And I agree
that \n\n (or code) is a good terminator.  I had been in the practice
of putting some TODOs together near the tops of my modules, but a
white line between would probably look cleaner anyway.

Phillip> there should be something besides just a comment to
Phillip> distinguish these things; like starting with a symbol (e.g.
Phillip> # !FIXME), so that that documentation extraction tools can
Phillip> distinguish code tags from other documentation that just
Phillip> happens to start with a CAPITALIZED word.

That might be necessary.  But if the extraction tools are aware of all
official codetags, then it becomes less important.  It might even be
useful for lint tools to comment when seeing a line that begins with
say "# FOO:" but isn't a codetag.  Most such uses probably fall under
one of the proposed categories anyway.

pythondev> It has always been my choice to *only* use XXX. I hope there
pythondev> aren't any developers contributing to the Python core who
pythondev> use any others?

$ csrcs=$(find ~/archive/Python-2.4.1 -name *.c)
$ for tag in '!!!' '\?\?\?' XXX WARN CAUTION \
TBD FIXME TODO BUG HACK Note NOTE RFE IMPORTANT; do
  echo -n "$tag: "; egrep"\b$tag" $csrcs |wc -l
  done
!!!: ~1
\?\?\?: ~12  [most of these part of XXXs]
XXX: 365
WARN: ~4
CAUTION: 16
TBD: ~2
FIXME: 12
TODO: 12
BUG: 0
HACK: 0
Note: ~306
NOTE: ~9
RFE: 0
IMPORTANT: ~6  [some overlap with NOTEs]

I subtracted most of the false positives but I think the model is
being implicitly used to a small degree already.  It's just hard to
know that they're in the code.  I'm impressed there are so few in 365
KLOC.  I also notice some WHO: initials, as well as Hmmm:, bad:,
Reference:, Obscure:, NB:, Bah:, and others.

pythondev> I honestly don't see much of a point for
pythondev> distinguishing different types; these are for humans to read
pythondev> and review, and different tags just makes it harder to grep.

Yes, they are hard to grep!  And so are XXXs if multi-line.  You'd
have to do something like "$EDITOR `grep -l XXX $csrcs`" to really
grok them.  That's why a different tool is needed for inspection.
Even if the codetag paradigm is despised for a given project,
something (pychecker/pylint) needs to do a proper scan to
address/remove/alert them.  I won't argue that the interpreter should
adopt codetags, but it would at least benefit from lint recognition.

Phillip> You still need a tracking system.

Agreed, for most projects, and I think Trac is great.  But some m

Re: [Python-Dev] Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py

[M.-A. Lemburg]

Bob Ippolito wrote:
> /usr/bin/sw_vers technically calls a private (at least undocumented)  
> CoreFoundation API, it doesn't parse that plist directly :)
> 
> On further inspection, it looks like parsing the plist directly is  
> supported API these days (see the bottom of  developer.apple.com/documentation/Carbon/Reference/Gestalt_Manager/ 
> gestalt_refchap/chapter_1.4_section_181.html>):
> 
> import plistlib
> dct = plistlib.Plist.fromFile('/System/Library/CoreServices/ 
> SystemVersion.plist')
> print '%(ProductName)s %(ProductVersion)s' % dct

Is the plistlib module always available on Mac OS X ?

Could you write a patch to system_alias() which uses
the above method if available for Mac OS ?

> -bob
> 
> On Sep 22, 2005, at 1:02 PM, Wilfredo Sánchez Vega wrote:
> 
> 
>>  "rhapsody" is emitted by uname on Mac OS X Server 1.x, but not on  
>>anything we ship today.
>>
>>  Bob's right, the version number from uname only tells you about  
>>the kernel, and not whether, for example, the Cocoa API is on the  
>>system (it wouldn't be on a standalone Darwin OS install, which  
>>will have the same uname output).
>>
>>  Just FYI, /usr/bin/sw_vers parses /System/Library/CoreServices/ 
>>SystemVersion.plist, which is XML.  If you want that info, parsing  
>>the file may be more efficient than forking off sw_vers.
>>
>>-wsv
>>
>>
>>On Sep 21, 2005, at 8:28 PM, Guido van Rossum wrote:
>>
>>
>>
>>>I forgot. The current code recognizes 'Rhapsody' and maps it to  
>>>"MacOS
>>>X Server". But I don't see any evidence that Apple still uses the  
>>>code
>>>name Rhapsody. Does uname ever return 'Rhapsody'?
>>>
>>
>>
> 
> ___
> 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/mal%40egenix.com

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
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] Adding a conditional expression in Py3.0

[Aahz]

On Wed, Sep 21, 2005, Nick Coghlan wrote:
> Steven Bethard wrote:
>> Guido van Rossum wrote:
>>> 
>>>I think I'd prefer (if  then  else ) i.e. no
>>>colons. None of the other  expression forms (list comprehensions and
>>>generator expressions) involving statement keywords use colons.
>> 
>> FWIW, I find this quite intuitive.  It follows the same pattern as LCs
>> and GEs -- remove the colons and add parentheses (or brackets for
>> LCs).  So I'm +1.
> 
> *But*, in LC's and GE's, the body of the main clause of the statement
> is also pulled out and placed in front of the keyword:
>
>def gen():
>  for VAR in ITERABLE:
>if COND:
>  yield EXPR
> 
> becomes:
> 
>gen = (EXPR for VAR in ITERABLE if COND)
> 
> This makes sense to me, because the most important thing in the
> generator expression is the way each element is populated - the source
> iterable and the filtering condition do matter, but they aren't as
> important.

Yes, and when the looping becomes the focal point, one should generally
rewrite a listcomp as a for loop.  Nevertheless, because boolean
expressions have non-boolean semantics in Python (i.e. they return the
objects rather than a boolean value), conditional expressions will
almost certainly have the condition as the focal point because a simple
boolean expression is no longer sufficient.  I am therefore strongly
opposed to the "a if cond else b" form.

(We've already agreed that Raymond's proposal to make boolean expressions
return booleans is dead, right?)

I'm also opposed to elif in conditional expressions -- let's keep this a
simple Pythonic rewrite of C's ternary.

I'm +0 on requiring parentheses precisely because they're annoying.  I'm
still expecting simple boolean expressions to be the primary use case,
and my hunch is that overall Python code will read better with the
ternary looking cluttered.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
___
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] Adding a conditional expression in Py3.0

[Raymond Hettinger]

[Aahz]
> I'm also opposed to elif in conditional expressions -- let's keep this
a
> simple Pythonic rewrite of C's ternary.
> 
> I'm +0 on requiring parentheses precisely because they're annoying.
I'm
> still expecting simple boolean expressions to be the primary use case,
> and my hunch is that overall Python code will read better with the
> ternary looking cluttered.

FWIW, I scanned the standard library for all the and/or pairings where a
conditional expression was applicable.  This sampling can serve as a
reference for what "typical" uses would look like in real Python code as
created by a number of different authors.

It only takes about five minutes to try out a given syntax proposal on
all the fragments listed below.  That short exercise provides an
excellent insight into the look and feel of each proposal in real world
code.


Raymond

-

cgitb.py: file = file and os.path.abspath(file) or '?'
cgitb.py: formatter = (self.format=="html") and html or text
compileal1.py: cfile = fullname + (__debug__ and 'c' or
'o')
csv.py:(quotes[a] > quotes[b]) and a or b,
quotes.keys())
csv.py:(delims[a] > delims[b]) and a or b,
delims.keys())
csv.py: modes[char] = reduce(lambda a, b: a[1] >
b[1] and a or b,
DocXMLRPCServer.py: anchor = (cl and cl.__name__ or '') + '-' +
name
fileinput.py:isfirstline() and "*"
or "", line)
formatter.py: self.writer.send_paragraph((blankline and 1)
or 0)
gettext.py: __builtin__.__dict__['_'] = unicode and
self.ugettext or self.gettext
imaplib.py: l = map(lambda x:'%s: "%s"' % (x[0], x[1][0] and
'" "'.join(x[1]) or ''), l)
imputil.py: _suffix_char = __debug__ and 'c' or 'o'
keyword.py: iptfile = args and args[0] or "Python/graminit.c"
pickle.py: self.write(obj and NEWTRUE or NEWFALSE)
pickle.py: self.write(obj and TRUE or FALSE)
pickletools.py:  pos is None and
"" or pos,
py_compile.py: cfile = file + (__debug__ and 'c' or 'o')
pydoc.py: return result and re.sub('^ *\n', '', rstrip(result)) or
''
pydoc.py: anchor = (cl and cl.__name__ or '') + '-' + name
pydoc.py: lhs = name and '%s = ' % name or ''
pydoc.py: contents = doc and [doc + '\n'] or []
pydoc.py: line = (name and name + ' = ' or '') + repr
pydoc.py: line = (name and self.bold(name) + ' = ' or '') + repr
pydoc.py: host = (sys.platform == 'mac') and '127.0.0.1' or
'localhost'
pydoc.py: font = ('helvetica', sys.platform == 'win32' and 8
or 10)
robotp~1.py: return (self.allowance and "Allow" or
"Disallow")+": "+self.path
telnet~1.py: cmd == DO and 'DO' or 'DONT',
ord(opt))
telnet~1.py: cmd == WILL and 'WILL' or
'WONT', ord(opt))
thread~1.py:n!=1 and "s" or "")
token.py: inFileName = args and args[0] or "Include/token.h"
tokenize.py: yield (parenlev > 0 and NL or NEWLINE,
unittest.py: return doc and doc.split("\n")[0].strip() or None
unittest.py: return doc and doc.split("\n")[0].strip() or None
unittest.py: (run, run != 1 and "s" or "",
timeTaken))
urllib.py: safe_map[c] = (c in safe) and c or ('%%%02X' % i)
urllib2.py: type = file and 'I' or 'D'
xdrlib.py: print pred(x) and 'succeeded' or 'failed',
':', x
xmlrpclib.py: write(value and "1" or "0")

___
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] inplace operators and __setitem__

[Aahz]

On Thu, Sep 29, 2005, Pierre Barbier de Reuille wrote:
>
> Ok, so I took a closer look at the documentation and tried a few things
> to understand better what you said and I have some remark ...

I've got some counter-remarks, but python-dev is not the place to
discuss them.  Please move this thread to comp.lang.python.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

The way to build large Python applications is to componentize and
loosely-couple the hell out of everything.
___
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] inplace operators and __setitem__

[Pierre Barbier de Reuille]

Done :)

I summarized my point of view and I'm waiting for comments :)

Pierre

Aahz a écrit :
> On Thu, Sep 29, 2005, Pierre Barbier de Reuille wrote:
> 
>>Ok, so I took a closer look at the documentation and tried a few things
>>to understand better what you said and I have some remark ...
> 
> 
> I've got some counter-remarks, but python-dev is not the place to
> discuss them.  Please move this thread to comp.lang.python.

-- 
Pierre Barbier de Reuille

INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France

tel   : (33) 4 67 61 65 77fax   : (33) 4 67 61 56 68
___
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] Pythonic concurrency

[Bruce Eckel]

I'd like to restart this discussion; I didn't mean to put forth active
objects as "the" solution, only that it seems to be one of the better,
more OO solutions that I've seen so far.

What I'd really like to figure out is the "pythonic" solution for
concurrency. Guido and I got as far as agreeing that it wasn't
threads.

Here are my own criteria for what such a solution would look like:

1) It works by default, so that novices can use it without falling
into the deep well of threading. That is, a program that you write
using threading is broken by default, and the tool you have to fix it
is "inspection." I want something that allows me to say "this is a
task. Go." and have it work without the python programmer having to
study and understand several tomes on the subject.

2) Tasks can be automatically distributed among processors, so it
solves the problems of (a) making python run faster (b) how to utilize
multiprocessor systems.

3) Tasks are cheap enough that I can make thousands of them, to solve
modeling problems (in which I also lump games). This is really a
solution to a cerain type of program complexity -- if I can just
assign a task to each logical modeling unit, it makes such a system
much easier to program.

4) Tasks are "self-guarding," so they prevent other tasks from
interfering with them. The only way tasks can communicate with each
other is through some kind of formal mechanism (something queue-ish,
I'd imagine).

5) Deadlock is prevented by default. I suspect livelock could still
happen; I don't know if it's possible to eliminate that.

6) It's natural to make an object that is actor-ish. That is, this
concurrency approach works intuitively with objects.

7) Complexity should be eliminated as much as possible. If it requires
greater limitations on what you can do in exchange for a clear,
simple, and safe programming model, that sounds pythonic to me. The
way I see it, if we can't easily use tasks without getting into
trouble, people won't use them. But if we have a model that allows
people to (for example) make easy use of multiple processors, they
will use that approach and the (possible) extra overhead that you pay
for the simplicity will be absorbed by the extra CPUs.

8) It should not exclude the possibility of mobile tasks/active
objects, ideally with something relatively straightforward such as
Linda-style tuple spaces.

One thing that occurs to me is that a number of items on this wish
list may conflict with each other, which may require a different way
of thinking about the problem. For example, it may require two
approaches: for "ordinary" non-OO tasks, a functional programming
approach ala Erlang, in combination with an actor approach for
objects.

Bruce Eckelhttp://www.BruceEckel.com   mailto:[EMAIL PROTECTED]
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel



___
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] Pythonic concurrency

[Michael Hudson]

Bruce Eckel <[EMAIL PROTECTED]> writes:

> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
>
> What I'd really like to figure out is the "pythonic" solution for
> concurrency. Guido and I got as far as agreeing that it wasn't
> threads.
>
> Here are my own criteria for what such a solution would look like:

Just because I've been mentioning it everywhere else since I read it,
have you seen this paper:

http://research.microsoft.com/Users/simonpj/papers/stm/

?  I don't know how applicable it would be to Python but it's well
worth the time it takes to read.

Cheers,
mwh

-- 
  This makes it possible to pass complex object hierarchies to
  a C coder who thinks computer science has made no worthwhile
  advancements since the invention of the pointer.
   -- Gordon McMillan, 30 Jul 1998
___
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] Adding a conditional expression in Py3.0

[Guido van Rossum]

On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> FWIW, I scanned the standard library for all the and/or pairings where a
> conditional expression was applicable.  This sampling can serve as a
> reference for what "typical" uses would look like in real Python code as
> created by a number of different authors.
>
> It only takes about five minutes to try out a given syntax proposal on
> all the fragments listed below.  That short exercise provides an
> excellent insight into the look and feel of each proposal in real world
> code.

I did this for my favorite proposal, and ended up with the list shown
further down below.

I think they all looks great!

The only problem is that it's not easy to come up with a regex-based
way to transform

C and X or Y

into

X if C else Y

because it's hard to determine where C starts. So I recommend that
people leave existing and/or code alone but start writing if/else
expressions in new code only. After all there's nothing wrong with
and/or.

cgitb.py: file = os.path.abspath(file) if file else '?'
cgitb.py: formatter = html if self.format == "html" else text
compileal1.py: cfile = fullname + ('c' if __debug__ else 'o')
csv.py:a if (quotes[a] > quotes[b]) else
b, quotes.keys())
csv.py:a if (delims[a] > delims[b]) else
b, delims.keys())
csv.py: modes[char] = reduce(lambda a, b: a if
a[1] > b[1] else b,
DocXMLRPCServer.py: anchor = (cl.__name__ if cl else '') + '-' + name
fileinput.py:"*" if isfirstline()
else "", line)
formatter.py: self.writer.send_paragraph((1) if blankline else 0)
gettext.py: __builtin__.__dict__['_'] = self.ugettext if
unicode else self.gettext
imaplib.py: l = map(lambda x:'%s: "%s"' % (x[0], '"
"'.join(x[1]) if x[1][0] else ''), l)
imputil.py: _suffix_char = 'c' if __debug__ else 'o'
keyword.py: iptfile = args[0] if args else "Python/graminit.c"
pickle.py: self.write(NEWTRUE if obj else NEWFALSE)
pickle.py: self.write(TRUE if obj else FALSE)
pickletools.py:  "" if pos is
None else pos,
py_compile.py: cfile = file + ('c' if __debug__ else 'o')
pydoc.py: return re.sub('^ *\n', '', rstrip(result)) if result else ''
pydoc.py: anchor = (cl.__name__ if cl else '') + '-' + name
pydoc.py: lhs = '%s = ' % name if name else ''
pydoc.py: contents = [doc + '\n'] if doc else []
pydoc.py: line = (name + ' = ' if name else '') + repr
pydoc.py: line = (self.bold(name) + ' = ' if name else '') + repr
pydoc.py: host = '127.0.0.1' if (sys.platform == 'mac')
else 'localhost'
pydoc.py: font = ('helvetica', 8 if sys.platform == 'win32' else 10)
robotp~1.py: return (self."Allow" if allowance else
"Disallow")+": "+self.path
telnet~1.py: 'DO' if cmd == DO else
'DONT', ord(opt))
telnet~1.py: 'WILL' if cmd == WILL else
'WONT', ord(opt))
thread~1.py:"s" if n!=1 else "")
token.py: inFileName = args[0] if args else "Include/token.h"
tokenize.py: yield (parenlev > NL if 0 else NEWLINE,
unittest.py: return doc.split("\n")[0].strip() if doc else None
unittest.py: return doc.split("\n")[0].strip() if doc else None
unittest.py: (run, run != "s" if 1 else
"", timeTaken))
urllib.py: safe_map[c] = c if (c in safe) else ('%%%02X' % i)
urllib2.py: type = 'I' if file else 'D'
xdrlib.py: print 'succeed' if pred(x) else 'failed', ':', x
xmlrpclib.py: write("1" if value else "0")

--
--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] Adding a conditional expression in Py3.0

[Guido van Rossum]

On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[a garbled list]
Stupid gmail broke the lines. Here it is again as an attachment.

--
--Guido van Rossum (home page: http://www.python.org/~guido/)


XifCelseY.py
Description: application/python
___
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] Adding a conditional expression in Py3.0

[Fredrik Lundh]

Guido van Rossum wrote:

> I think they all looks great!

expression if expression?

looks like you've been doing too much Perl hacking lately ;-)

 



___
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] Adding a conditional expression in Py3.0

[Antoine Pitrou]

> The only problem is that it's not easy to come up with a regex-based
> way to transform
> 
> C and X or Y
> 
> into
> 
> X if C else Y

(my 2 cents)

I find this proposal very confusing. The order is not logical at all.
One usually expects to find the condition on one side, and the
alternatives on another side (this is how it's done in every conditional
construct I know of : traditional if-then-else, lisp's cond, switch
statements...). But there the condition is in the middle, which breaks
the natural reading order and feels obfuscated.

This is especially true if the "X" in "X if C else Y" happens to be a
non-trivial expression - witness your example from unittest.py:
return doc.split("\n")[0].strip() if doc else None

... because then the condition (which is the most important part of the
statement) is shadowed by the complexity of the first alternative; and
the two alternatives, which should logically be siblings, are separated
by something which has a different role in the construct.

This is exactly like a switch/case statement where the "switch" would
have to be inserted in the middle of two "case"'s.

Also, generally, one of the most annoying things in computer languages
is when they try to invent their own unnatural conditional forms: such
as Perl's inverted forms or "unless" statement.

Regards

Antoine.


___
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] Adding a conditional expression in Py3.0

[skip]

Guido> After all there's nothing wrong with and/or.

Especially if it's correct. 

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/archive%40mail-archive.com

Re: [Python-Dev] Adding a conditional expression in Py3.0

[Nick Coghlan]

Raymond Hettinger wrote:
> [Aahz]
> 
>>I'm also opposed to elif in conditional expressions -- let's keep this
> 
> a
> 
>>simple Pythonic rewrite of C's ternary.
>>
>>I'm +0 on requiring parentheses precisely because they're annoying.
> 
> I'm
> 
>>still expecting simple boolean expressions to be the primary use case,
>>and my hunch is that overall Python code will read better with the
>>ternary looking cluttered.
> 
> 
> FWIW, I scanned the standard library for all the and/or pairings where a
> conditional expression was applicable.  This sampling can serve as a
> reference for what "typical" uses would look like in real Python code as
> created by a number of different authors.

Thanks for digging those out - I was thinking that would be a useful exercise, 
but hadn't taken the time to think of an easy way to find relevant lines.

> It only takes about five minutes to try out a given syntax proposal on
> all the fragments listed below.  That short exercise provides an
> excellent insight into the look and feel of each proposal in real world
> code.

I tried it with (if C then A else B) and (A if C else B), and found both to be 
significantly more readable than the current code.

In particular, I wouldn't want to bet money that none of the examples are 
buggy, as there were a few cases where the "A" value could conceivably be 0 or 
'', but I couldn't tell if it was possible for the condition to also be true 
in those cases.

Comparing the two syntaxes I tried, I found that the infix notation generally 
required the addition of parentheses around the "A" expression when that 
expression was itself a binary operation - otherwise the precedence was 
unclear and, even with parentheses around the whole conditional, the layout 
gave the impression that the conditional expression only applied to the second 
argument to the binary operation in "A".

That said, the more verbose form still felt like it had the elements out of 
sequence - it was just crying out for the expression to be rewritten as a 
statement.

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.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] Pythonic concurrency

[Bruce Eckel]

This paper looks very interesting and promises some good ideas. It
also looks like it will require time and effort to digest.

I've only read the first few pages, but one thing that does leap out
is at the beginning of section 3, they say:

"... a purely-declarative language is a perfect setting for
transactional memory."

What's not clear to me from this is whether STM will work in a
non-declarative language like Python.

Thursday, September 29, 2005, 8:12:23 AM, Michael Hudson wrote:

> Bruce Eckel <[EMAIL PROTECTED]> writes:

>> I'd like to restart this discussion; I didn't mean to put forth active
>> objects as "the" solution, only that it seems to be one of the better,
>> more OO solutions that I've seen so far.
>>
>> What I'd really like to figure out is the "pythonic" solution for
>> concurrency. Guido and I got as far as agreeing that it wasn't
>> threads.
>>
>> Here are my own criteria for what such a solution would look like:

> Just because I've been mentioning it everywhere else since I read it,
> have you seen this paper:

> http://research.microsoft.com/Users/simonpj/papers/stm/

> ?  I don't know how applicable it would be to Python but it's well
> worth the time it takes to read.

> Cheers,
> mwh



Bruce Eckelhttp://www.BruceEckel.com   mailto:[EMAIL PROTECTED]
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
Subscribe to my newsletter:
http://www.mindview.net/Newsletter
My schedule can be found at:
http://www.mindview.net/Calendar



___
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] Adding a conditional expression in Py3.0

[Nick Coghlan]

Antoine Pitrou wrote:
> This is especially true if the "X" in "X if C else Y" happens to be a
> non-trivial expression - witness your example from unittest.py:
> return doc.split("\n")[0].strip() if doc else None
> 
> ... because then the condition (which is the most important part of the
> statement) is shadowed by the complexity of the first alternative; and
> the two alternatives, which should logically be siblings, are separated
> by something which has a different role in the construct.

I think the perception of what's important is relevant here - to me, the 
behaviour in the normal case (i.e., non-empty doc) is the most important 
element. The conditional, and the default value returned when 'doc' is empty 
are interesting, but are a corner case, rather than a fundamental element of 
the function's behaviour.

> This is exactly like a switch/case statement where the "switch" would
> have to be inserted in the middle of two "case"'s.

Well, no - because it is possible to consider an if-else as a parameterised 
binary operation that chooses between the left and right operands (i.e., it's 
like an "or", only we're asking that the decision be made based on something 
other than the truth value of the left hand operand).

That is, in the case where the left hand expression has no side effects, the 
following pairs of expression are essentially equivalent:

   a or b <-> a if a else b
   a and b <-> a if not a else b

In the switch statement example, the switch statement is inherently an n-ary 
operation, so there is no comparable way of finding a spot to put the switch 
variable "in the middle".

> Also, generally, one of the most annoying things in computer languages
> is when they try to invent their own unnatural conditional forms: such
> as Perl's inverted forms or "unless" statement.

Even more annoying are constructs that don't gel with the rest of the 
language, though.

Regards,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://boredomandlaziness.blogspot.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

[Python-Dev] 64-bit bytecode compatibility (was Re: [PEAK] ez_setup on 64-bit linux problem)

[Phillip J. Eby]

At 09:49 AM 9/29/2005 -0400, Viren Shah wrote:
>[I sent this earlier without being a subscriber and it was sent to the 
>moderation queue so I'm resending it after subscribing]
>
>Hi,
>   I'm running a 64-bit Fedora Core 3 with python 2.3.4. I'm trying to 
> install setuptools to use with Trac, and get the following error:
>
>  [EMAIL PROTECTED] ~]$ python ez_setup.py
>Downloading 
>http://cheeseshop.python.org/packages/2.3/s/setuptools/setuptools-0.6a4-py2.3.egg
>Traceback (most recent call last):
>   File "ez_setup.py", line 206, in ?
> main(sys.argv[1:])
>   File "ez_setup.py", line 141, in main
> from setuptools.command.easy_install import main
>OverflowError: signed integer is greater than maximum
>
>
>I get the same type of error if I try installing setuptools manually. I 
>figure this has to do with the 64-bit nature of the OS and python, but not 
>being a python person, don't know what a workaround would be.
>
>Any ideas?

Hm.  It sounds like perhaps the 64-bit Python in question isn't able to 
read bytecode for Python from a 32-bit Python version.  You'll need to 
download the setuptools source archive from PyPI and install it using 
"python setup.py install" instead.

In the meantime, I'm going to inquire on Python-Dev about whether a 64-bit 
Python should be able to read 32-bit bytecode, as I was under the 
impression Python's bytecode format was supposed to be cross-platform.  See 
e.g.:

http://mail.python.org/pipermail/python-list/2004-March/213039.html

___
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] Pythonic concurrency

[Michael Walter]

FWIW, the Perl 6 community is also investigating STM, so it appears to
be a worthwhile idea for an impure, multi-paradigm language as well.

Regards,
Michael

On 9/29/05, Bruce Eckel <[EMAIL PROTECTED]> wrote:
> This paper looks very interesting and promises some good ideas. It
> also looks like it will require time and effort to digest.
>
> I've only read the first few pages, but one thing that does leap out
> is at the beginning of section 3, they say:
>
> "... a purely-declarative language is a perfect setting for
> transactional memory."
>
> What's not clear to me from this is whether STM will work in a
> non-declarative language like Python.
>
> Thursday, September 29, 2005, 8:12:23 AM, Michael Hudson wrote:
>
> > Bruce Eckel <[EMAIL PROTECTED]> writes:
>
> >> I'd like to restart this discussion; I didn't mean to put forth active
> >> objects as "the" solution, only that it seems to be one of the better,
> >> more OO solutions that I've seen so far.
> >>
> >> What I'd really like to figure out is the "pythonic" solution for
> >> concurrency. Guido and I got as far as agreeing that it wasn't
> >> threads.
> >>
> >> Here are my own criteria for what such a solution would look like:
>
> > Just because I've been mentioning it everywhere else since I read it,
> > have you seen this paper:
>
> > http://research.microsoft.com/Users/simonpj/papers/stm/
>
> > ?  I don't know how applicable it would be to Python but it's well
> > worth the time it takes to read.
>
> > Cheers,
> > mwh
>
>
>
> Bruce Eckelhttp://www.BruceEckel.com   mailto:[EMAIL PROTECTED]
> Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
> Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
> Subscribe to my newsletter:
> http://www.mindview.net/Newsletter
> My schedule can be found at:
> http://www.mindview.net/Calendar
>
>
>
> ___
> 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/michael.walter%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] Adding a conditional expression in Py3.0

[Edward C. Jones]

Guido van Rossum wrote:

file = os.path.abspath(file) if file else '?'
...

These are all unreadable. In C "a ? b : c" is not used very often. A 
quick check of the Python source found 476 occurences.

-1 to conditional expressions.
___
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] Adding a conditional expression in Py3.0

[Steve Holden]

Guido van Rossum wrote:
> On 9/29/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> 
>>FWIW, I scanned the standard library for all the and/or pairings where a
>>conditional expression was applicable.  This sampling can serve as a
>>reference for what "typical" uses would look like in real Python code as
>>created by a number of different authors.
>>
>>It only takes about five minutes to try out a given syntax proposal on
>>all the fragments listed below.  That short exercise provides an
>>excellent insight into the look and feel of each proposal in real world
>>code.
> 
> 
> I did this for my favorite proposal, and ended up with the list shown
> further down below.
> 
> I think they all looks great!
> 
The fact that so few were found in whole of the standard library does 
put the use case into question, though, no? Though I am sure more could 
be found with a more thorough scan.

> The only problem is that it's not easy to come up with a regex-based
> way to transform
> 
> C and X or Y
> 
> into
> 
> X if C else Y
> 
> because it's hard to determine where C starts. So I recommend that
> people leave existing and/or code alone but start writing if/else
> expressions in new code only. After all there's nothing wrong with
> and/or.
> 
> cgitb.py: file = os.path.abspath(file) if file else '?'
> cgitb.py: formatter = html if self.format == "html" else text
> compileal1.py: cfile = fullname + ('c' if __debug__ else 'o')
> csv.py:a if (quotes[a] > quotes[b]) else
> b, quotes.keys())
> csv.py:a if (delims[a] > delims[b]) else
> b, delims.keys())
> csv.py: modes[char] = reduce(lambda a, b: a if
> a[1] > b[1] else b,
> DocXMLRPCServer.py: anchor = (cl.__name__ if cl else '') + '-' + name
> fileinput.py:"*" if isfirstline()
> else "", line)
> formatter.py: self.writer.send_paragraph((1) if blankline else 0)
> gettext.py: __builtin__.__dict__['_'] = self.ugettext if
> unicode else self.gettext
> imaplib.py: l = map(lambda x:'%s: "%s"' % (x[0], '"
> "'.join(x[1]) if x[1][0] else ''), l)
> imputil.py: _suffix_char = 'c' if __debug__ else 'o'
> keyword.py: iptfile = args[0] if args else "Python/graminit.c"
> pickle.py: self.write(NEWTRUE if obj else NEWFALSE)
> pickle.py: self.write(TRUE if obj else FALSE)
> pickletools.py:  "" if pos is
> None else pos,
> py_compile.py: cfile = file + ('c' if __debug__ else 'o')
> pydoc.py: return re.sub('^ *\n', '', rstrip(result)) if result else ''
> pydoc.py: anchor = (cl.__name__ if cl else '') + '-' + name
> pydoc.py: lhs = '%s = ' % name if name else ''
> pydoc.py: contents = [doc + '\n'] if doc else []
> pydoc.py: line = (name + ' = ' if name else '') + repr
> pydoc.py: line = (self.bold(name) + ' = ' if name else '') + repr
> pydoc.py: host = '127.0.0.1' if (sys.platform == 'mac')
> else 'localhost'
> pydoc.py: font = ('helvetica', 8 if sys.platform == 'win32' else 
> 10)
> robotp~1.py: return (self."Allow" if allowance else
> "Disallow")+": "+self.path
> telnet~1.py: 'DO' if cmd == DO else
> 'DONT', ord(opt))
> telnet~1.py: 'WILL' if cmd == WILL else
> 'WONT', ord(opt))
> thread~1.py:"s" if n!=1 else "")
> token.py: inFileName = args[0] if args else "Include/token.h"
> tokenize.py: yield (parenlev > NL if 0 else NEWLINE,
> unittest.py: return doc.split("\n")[0].strip() if doc else None
> unittest.py: return doc.split("\n")[0].strip() if doc else None
> unittest.py: (run, run != "s" if 1 else
> "", timeTaken))
> urllib.py: safe_map[c] = c if (c in safe) else ('%%%02X' % i)
> urllib2.py: type = 'I' if file else 'D'
> xdrlib.py: print 'succeed' if pred(x) else 'failed', ':', x
> xmlrpclib.py: write("1" if value else "0")
> 

Having though about it more closely, the reason I believe it might 
confuse newbies is because until the "else" comes along the construct 
can easily be read as a statement with a conditional suffix, and it's 
only after you read the "else" it becomes obvious that it's the 
expression that's conditional.

I realise that this reading will become habitual once this proposal is 
put into the language, but I do think this will be a source of confusion 
to newcomers (who should anyway be steered away from all the magic of 
ternary expressions, list comprehensions, generator expressions and the 
like.

I would argue for mandatory parentheses around the expression, leaving 
room later (probably after Guido is no longer around to be sick at the 
site of it) for:

def f(condition):
 return something if condition # no else!
 return so

Re: [Python-Dev] PEP 350: Codetags

[Phillip J. Eby]

At 09:10 AM 9/28/2005 -0700, Micah Elliott wrote:
>I agree that proof of value is necessary.  Without a spec though it
>will be hard to get people to know about a convention/toolset, so it's
>a bit of a chicken-egg problem -- I can't have a pep until the tools are
>in use, but the tools won't be used until programmers have
>means/motivation to use them, a pep.

My point about the lack of motivation was that there was little reason 
shown why this should be a PEP instead of either:

1. Documentation for a specific tool, or group of tools
2. A specific project's process documentation

Are you proposing that this format be used by the Python developers for 
Python itself?  A process spec like this seems orthogonal to 
Python-the-language.

To put it another way, this seems like writing a PEP on how to do eXtreme 
Programming, or perhaps a PEP on how the blogging "trackback" protocol 
works.  Certainly you might implement those things using Python, but the 
spec itself seems entirely orthogonal to Python.  I don't really see why 
it's a PEP, as opposed to just a published spec on your own website, unless 
you intend for say, the Python stdlib to conform to it.

___
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] Pythonic concurrency

[Phillip J. Eby]

At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:
>This paper looks very interesting and promises some good ideas. It
>also looks like it will require time and effort to digest.
>
>I've only read the first few pages, but one thing that does leap out
>is at the beginning of section 3, they say:
>
>"... a purely-declarative language is a perfect setting for
>transactional memory."
>
>What's not clear to me from this is whether STM will work in a
>non-declarative language like Python.

I spent a few weekends studying that paper earlier this year in order to 
see if anything could be stolen for Python; my general impression was "not 
easily" at the least.  One notable feature of the presented concept was 
that when code would otherwise block, they *rolled it back* to the last 
nonblocking execution point.  In a sense, they ran the code backwards, 
albeit by undoing its effects.  They then suspend execution until there's a 
change to at least one of the variables read during the forward execution, 
to avoid repeated retries.

It was a really fascinating idea, because it was basically a way to write 
nonblocking code without explicit yielding constructs.  But, it depends 
utterly on having all changes to data being transactional, and on being 
able to guarantee it in order to prevent bugs that would be just as bad as 
the ones you get from threading.

Oddly enough, this paper actually demonstrates a situation where having 
static type checking is in fact a solution to a non-trivial problem!  It 
uses static type checking of monads to ensure that you can't touch 
untransacted things inside a transaction.

___
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] Adding a conditional expression in Py3.0

[Ron Adam]

Antoine Pitrou wrote:
>>The only problem is that it's not easy to come up with a regex-based
>>way to transform
>>
>>C and X or Y
>>
>>into
>>
>>X if C else Y


One way is to parse it manually to a list.  This was just a test, but 
more samples can be added friarly easy.

samples = [
 # start, cond,  x,  y, end
 ("cgitb.py:  file =", "file", "os.path.abspath(file)", "'?'", ""),
 ("cgitb.py:  formatter =", '(self.format=="html")', "html", "text", 
""),
 ("compileal1.py: cfile = fullname + (", "__debug__","'c'","'o'",")"),
 ]

for s,c,x,y,e in samples:
 print "%s %s and %s or %s %s" % (s,c,x,y,e)
 print "%s %s if %s else %s %s" % (s,x,c,y,e)
 print "%s (if %s then %s else %s) %s" % (s,c,x,y,e)
 print "%s (%s ? %s : %s) %s" % (s,c,x,y,e)
 print



> (my 2 cents)
> 
> I find this proposal very confusing. The order is not logical at all.
> One usually expects to find the condition on one side, and the
> alternatives on another side (this is how it's done in every conditional
> construct I know of : traditional if-then-else, lisp's cond, switch
> statements...). But there the condition is in the middle, which breaks
> the natural reading order and feels obfuscated.


I found that my preference depends on the situation.  I like (if cond 
then expr1 else expr2) for most things because having the condition in 
front tells me the purpose, And it's better represents the order the 
terms are evaluated in.

But when checking a value and either changing it or leaving it alone, I 
tended to want to type it as.

  value = (value if cond else alternate_value)

In this case the condition is an accept or reject for the 
alternate_value.  And since the first term is a simple name instead of a 
complex expression, the order of evaluation doesn't bother me.


Personally I prefer the function form best for the pure simplicity of 
it,  if(cond, e1, e2),  but of course that doesn't do the shortcut 
behavior and it pre-evaluates the arguments, so it's not an answer.

Cheers,
Ron


___
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] 64-bit bytecode compatibility (was Re: [PEAK] ez_setup on 64-bit linux problem)

[Phillip J. Eby]

At 12:14 PM 9/29/2005 -0400, Viren Shah wrote:
>   File "/root/svn-install-apps/setuptools-0.6a4/pkg_resources.py", line 
> 949, in _get
> return self.loader.get_data(path)
>OverflowError: signed integer is greater than maximum

Interesting.  That looks like it might be a bug in the Python zipimport 
module, which is what implements get_data().  Apparently it happens upon 
importing as well; I assumed that it was a bytecode incompatibility.

Checking the revision log, I find that there's a 64-bit fix for zipimport.c 
in Python 2.4 that looks like it would fix this issue, but it has not been 
backported to any revision of Python 2.3.  You're going to either have to 
backport the fix yourself and rebuild Python 2.3, or upgrade to Python 
2.4.  Sorry.  :(

The diff that implements the fix is at:

http://cvs.sourceforge.net/viewcvs.py/python/python/dist/src/Modules/zipimport.c?r1=1.16&r2=1.17

I'll update my documentation pages to reflect that setuptools requires 
Python 2.4 if you're using a 64-bit Python.

___
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] Adding a conditional expression in Py3.0

[Guido van Rossum]

On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
> I would argue for mandatory parentheses around the expression, leaving
> room later (probably after Guido is no longer around to be sick at the
> site of it) for:
>
> def f(condition):
>  return something if condition # no else!
>  return somethingElse
>
> not-expecting-this-to-fly-ly y'rs  - steve

Let me give you what you expect. If all the "X if C else Y" syntax
does is prevent that atrocity from ever being introduced, it would be
worth it. :)

--
--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] Pythonic concurrency

[Bruce Eckel]

> I spent a few weekends studying that paper earlier this year in order to
> see if anything could be stolen for Python; my general impression was "not
> easily" at the least.  One notable feature of the presented concept was
> that when code would otherwise block, they *rolled it back* to the last
> nonblocking execution point.  In a sense, they ran the code backwards,
> albeit by undoing its effects.  They then suspend execution until there's a
> change to at least one of the variables read during the forward execution,
> to avoid repeated retries.

I haven't spent the weekends on the paper yet (but it looks like that
is what it would take), but I had the impression that they were
talking about the lock-free techniques such as the ones used in Java
5. Basically, you start a write operation "in the background" without
locking the data structure, so reads can continue while the
calculation is taking place but before the result is committed. When
the result is ready, an atomic "test and write" operation is used to
determine whether any other task has modified the value in the
meantime, and if not to commit the new value. If another task did
modify the value, then the calculation begins anew.

That was my take, but I haven't studied everything about STM yet, so
I'm probably missing something.

The one thing about this paper is that it seems to be an orthogonal
perspective to anything about concurrency that *I* have seen before.

> Oddly enough, this paper actually demonstrates a situation where having
> static type checking is in fact a solution to a non-trivial problem!  It
> uses static type checking of monads to ensure that you can't touch 
> untransacted things inside a transaction.

Yes, because of some of my diatribes against static checking people
get the impression that I think it's just a bad thing. However, I'm
really trying to get across the idea that "static type checking as the
solution to all problems is a bad idea," and that the cost is often
much greater than the benefit. But if there really is a clear payoff
then I'm certainly not averse to it. In general, I really *do* like to
be told when something has gone wrong -- I think there's a huge
benefit in that. But if I can learn about it at runtime rather than
compile time, then that is often a reasonable solution.

So with concurrency, I would like to know when I do something wrong,
but if I am told at runtime that's OK with me as long as I'm told.

Bruce Eckelhttp://www.BruceEckel.com   mailto:[EMAIL PROTECTED]
Contains electronic books: "Thinking in Java 3e" & "Thinking in C++ 2e"
Web log: http://www.artima.com/weblogs/index.jsp?blogger=beckel
Subscribe to my newsletter:
http://www.mindview.net/Newsletter
My schedule can be found at:
http://www.mindview.net/Calendar



___
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 350: Codetags

[Paul Moore]

On 9/29/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> My point about the lack of motivation was that there was little reason
> shown why this should be a PEP instead of either:
>
> 1. Documentation for a specific tool, or group of tools
> 2. A specific project's process documentation

That's what I feel as well. I hadn't commented on the PEP as I had
simply intended to ignore it totally in my own projects...

Paul.
___
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] Pythonic concurrency

[Bill Janssen]

> 1) It works by default, so that novices can use it without falling
> into the deep well of threading. That is, a program that you write
> using threading is broken by default, and the tool you have to fix it
> is "inspection." I want something that allows me to say "this is a
> task. Go." and have it work without the python programmer having to
> study and understand several tomes on the subject.

Bruce, this seems to me like wishful thinking.  Either the separate
threads don't interact, in which case you are running separate
programs, in which case os.system() already works well enough, or they
do, in which case you have the various deadlock and livelock problems
of threading.

And this nonsense about threaded programs being "broken by default" --
might as well say the same about programs that use variables.  If you
don't know how to use threads, great, just don't use them.  Spend the
time reading Fred Brooks' NO SILVER BULLET, instead.  It's available
in essay form at
http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html.

> One thing that occurs to me is that a number of items on this wish
> list may conflict with each other, which may require a different way
> of thinking about the problem.

That seems correct to me.

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] Pythonic concurrency

[Phillip J. Eby]

At 10:48 AM 9/29/2005 -0600, Bruce Eckel wrote:
>I haven't spent the weekends on the paper yet (but it looks like that
>is what it would take), but I had the impression that they were
>talking about the lock-free techniques such as the ones used in Java
>5. Basically, you start a write operation "in the background" without
>locking the data structure, so reads can continue while the
>calculation is taking place but before the result is committed. When
>the result is ready, an atomic "test and write" operation is used to
>determine whether any other task has modified the value in the
>meantime, and if not to commit the new value. If another task did
>modify the value, then the calculation begins anew.
>
>That was my take, but I haven't studied everything about STM yet, so
>I'm probably missing something.

No, that's certainly the general idea.  The issue for an imperative 
language like Python is that side-effects are the norm, rather than an 
exception.  The Haskell implementation of the idea effectively relies on 
the fact that in Haskell you have to jump through monadic hoops to get side 
effects, so if you have a low-level transactional memory facility, you can 
create monadic combinators that restrict those side effects to occuring in 
the way you want them to.  This is so utterly alien to Python's execution 
model - or indeed most imperative languages' execution models - that I 
don't see how it can be modelled in Python in a way that retains the 
significant benefits of the approach.

Now, in PyPy, I suppose it might be possible to create a custom 
object-space that works that way, and I hadn't thought of that 
before.  Maybe you should run that paper past one of the PyPy wizards and 
see if you can get them interested in the idea, then stand back and see 
what happens.  :)


>The one thing about this paper is that it seems to be an orthogonal
>perspective to anything about concurrency that *I* have seen before.

Yes - it's dramatically different, and seems like the One True Way to do 
imperative concurrency with side-effects.  Certainly transactions work 
nicely for databases, anyway.  :)


>So with concurrency, I would like to know when I do something wrong,
>but if I am told at runtime that's OK with me as long as I'm told.

Yeah, but in current Python implementations - with the possible exception 
of PyPY - detecting the problem at all is virtually impossible.  PyPy is an 
extensible VM, though, so in principle you could create some kind of 
transactional object space that could keep track of things and tell you if 
you mess up.

___
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] Pythonic concurrency

[Michael Hudson]

"Phillip J. Eby" <[EMAIL PROTECTED]> writes:

> At 09:30 AM 9/29/2005 -0600, Bruce Eckel wrote:
>>This paper looks very interesting and promises some good ideas. It
>>also looks like it will require time and effort to digest.
>>
>>I've only read the first few pages, but one thing that does leap out
>>is at the beginning of section 3, they say:
>>
>>"... a purely-declarative language is a perfect setting for
>>transactional memory."
>>
>>What's not clear to me from this is whether STM will work in a
>>non-declarative language like Python.
>
> I spent a few weekends studying that paper earlier this year in order to 
> see if anything could be stolen for Python; my general impression was "not 
> easily" at the least.  One notable feature of the presented concept was 
> that when code would otherwise block, they *rolled it back* to the last 
> nonblocking execution point.  In a sense, they ran the code backwards, 
> albeit by undoing its effects.  They then suspend execution until there's a 
> change to at least one of the variables read during the forward execution, 
> to avoid repeated retries.
>
> It was a really fascinating idea, because it was basically a way to write 
> nonblocking code without explicit yielding constructs.  But, it depends 
> utterly on having all changes to data being transactional, and on being 
> able to guarantee it in order to prevent bugs that would be just as bad as 
> the ones you get from threading.

Oh yes, if implemented this really has be baked thoroughly into the
implementation.  It's not something that can be implemented as a
library (as far as I can see, anyway).

> Oddly enough, this paper actually demonstrates a situation where having 
> static type checking is in fact a solution to a non-trivial problem!  It 
> uses static type checking of monads to ensure that you can't touch 
> untransacted things inside a transaction.

Well, this is an extension of the way Haskell deals with side-effects
in general... but yes, it's interesting to be sure.

Cheers,
mwh

-- 
  People think I'm a nice guy, and the fact is that I'm a scheming,
  conniving bastard who doesn't care for any hurt feelings or lost
  hours of work if it just results in what I consider to be a better
  system.-- Linus Torvalds
___
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] Adding a conditional expression in Py3.0

[Raymond Hettinger]

> > It only takes about five minutes to try out a given syntax proposal
on
> > all the fragments listed below.  That short exercise provides an
> > excellent insight into the look and feel of each proposal in real
world
> > code.
> 
> I did this for my favorite proposal, and ended up with the list shown
> further down below.
> 
> I think they all looks great!

They mostly look great to me too :-)

The exceptions are the ones in pydoc which have an odd feel to them and,
to my eyes, don't parse well.  I can't put my finger on the issue -- it
could be that any ternary operator syntax breaks down when used in
series with other operators or when there are complex sub-expressions.


> pydoc.py: return re.sub('^ *\n', '', rstrip(result)) if result
else ''
> pydoc.py: anchor = (cl.__name__ if cl else '') + '-' + name
> pydoc.py: lhs = '%s = ' % name if name else
''
> pydoc.py: contents = [doc + '\n'] if doc else []
> pydoc.py: line = (name + ' = ' if name else '') + repr
> pydoc.py: line = (self.bold(name) + ' = ' if name else '') +
repr
> pydoc.py: host = '127.0.0.1' if (sys.platform == 'mac')
else 'localhost'
> pydoc.py: font = ('helvetica', 8 if sys.platform ==
'win32' else 10)

There is one that looks like it could be completely mis-interpreted:

   (name + ' = ' if name else '')   # as written above
   ((name + ' = ') if name else '') # one mental interpretation
   (name + (' = ' if name else '')) # an incorrect interpretation

The grouping issue doesn't arise for syntaxes that start with a keyword:
   (if name then name + ' = ' else '')
but even those suffer from unclear precedence when used with binary
operations on the right:   (if cond then a else b + c).  



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] Pythonic concurrency

[Jim Fulton]

Michael Hudson wrote:
> Bruce Eckel <[EMAIL PROTECTED]> writes:
> 
> 
>>I'd like to restart this discussion; I didn't mean to put forth active
>>objects as "the" solution, only that it seems to be one of the better,
>>more OO solutions that I've seen so far.
>>
>>What I'd really like to figure out is the "pythonic" solution for
>>concurrency. Guido and I got as far as agreeing that it wasn't
>>threads.
>>
>>Here are my own criteria for what such a solution would look like:
> 
> 
> Just because I've been mentioning it everywhere else since I read it,
> have you seen this paper:
> 
> http://research.microsoft.com/Users/simonpj/papers/stm/
> 
> ?  I don't know how applicable it would be to Python but it's well
> worth the time it takes to read.

I haven't read more than the abstract and the responses to the paper
here, but I think I have the gist. (I look forward to reading it later.)

I'll note that we have experience with something less rigorous
than but otherwise similar to this with ZODB.  We often have tens of
processes working on the same data, synchronizing through a common
object store.  Each process executes transactions which are written
without any threading code at all.  Processes synchronize through
transaction commits.  This model has worked very well for Zope,
at least as long as conflicts can be kept to a minimum. :)

The ZODB approach is less rigorous as it only works when your processes
operate soley on database objects, but it provides a useful example,
I think, of applying this model in Python and it probably covers a
reasonably large set of interesting applications.  There are
hundreds (possibly thousands) of programmers who have used this technique
in Zope, probably without even realizing that they were doing concurrent 
programming.

J2EE systems use a similar approach.

Jim

-- 
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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] C API doc fix

[Robey Pointer]

Yesterday I ran into a bug in the C API docs.  The top of this page:

 http://docs.python.org/api/unicodeObjects.html

says:

Py_UNICODE
 This type represents a 16-bit unsigned storage type which is  
used by Python internally as basis for holding Unicode ordinals. On  
platforms where wchar_t is available and also has 16-bits, Py_UNICODE  
is a typedef alias for wchar_t to enhance native platform  
compatibility. On all other platforms, Py_UNICODE is a typedef alias  
for unsigned short.


This is incorrect on some platforms: on Debian, Py_UNICODE turns out  
to be 32 bits.

I'm not sure what the correct quote should be: Does python use  
wchar_t whenever it's available (16 bits or not)?

I solved my problem by realizing that I was going about things  
entirely wrong, and that I should use the python codecs from C and  
not worry about what Py_UNICODE contains.  However, I think we should  
fix the docs to avoid confusing others... or maybe it would be better  
to document what's in Py_UNICODE and suggest always using the codec  
methods?  I don't have a strong opinion either way.

robey

___
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 doc fix

[Steven Bethard]

On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
> Yesterday I ran into a bug in the C API docs.  The top of this page:
>
>  http://docs.python.org/api/unicodeObjects.html
>
> says:
>
> Py_UNICODE
>  This type represents a 16-bit unsigned storage type which is
> used by Python internally as basis for holding Unicode ordinals. On
> platforms where wchar_t is available and also has 16-bits, Py_UNICODE
> is a typedef alias for wchar_t to enhance native platform
> compatibility. On all other platforms, Py_UNICODE is a typedef alias
> for unsigned short.

I believe this is the same issue that was brought up in May[1].  My
impression was that people could not agree on a documentation patch.

[1] http://www.python.org/dev/summary/2005-05-01_2005-05-15.html

STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] Pythonic concurrency

[Shane Hathaway]

Bruce Eckel wrote:
> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.
> 
> What I'd really like to figure out is the "pythonic" solution for
> concurrency. Guido and I got as far as agreeing that it wasn't
> threads.

I've pondered this problem.  Python deals programmers a double whammy 
when it comes to threads: not only is threading unsafe like it is in 
other languages, but the GIL also prevents you from using multiple 
processors.  Thus there's more pressure to improve concurrency in Python 
than there is elsewhere.

I like to use fork(), but fork has its own set of surprises.  In 
particular, in the programmer's view, forking creates a disassociated 
copy of every object except files.  Also, there's no Pythonic way for 
the two processes to communicate once the child has started.

It's tempting to create a library around fork() that solves the 
communication problem, but the copied objects are still a major source 
of bugs.  Imagine what would happen if you forked a Zope process with an 
open ZODB.  If both the parent and child change ZODB objects, ZODB is 
likely to corrupt itself, since the processes share file descriptors. 
Thus forking can just as dangerous as threading.

Therefore, I think a better Python concurrency model would be a lot like 
the subprocess module, but designed for calling Python code.  I can 
already think of several ways I would use such a module.  Something like 
the following would solve problems I've encountered with threads, 
forking, and the subprocess module:

 import pyprocess
 proc = pyprocess.start('mypackage.mymodule', 'myfunc', arg1, arg2=5)
 while proc.running():
 # do something else
 res = proc.result()

This code doesn't specify whether the subprocess should continue to 
exist after the function completes (or throws an exception).  I can 
think of two ways to deal with that:

1) Provide two APIs.  The first API stops the subprocess upon function 
completion.  The second API allows the parent to call other functions in 
the subprocess, but never more than one function at a time.

2) Always leave subprocesses running, but use a 'with' statement to 
guarantee the subprocess will be closed quickly.  I prefer this option.

I think my suggestion fits most of your objectives.

> 1) It works by default, so that novices can use it without falling
> into the deep well of threading. That is, a program that you write
> using threading is broken by default, and the tool you have to fix it
> is "inspection." I want something that allows me to say "this is a
> task. Go." and have it work without the python programmer having to
> study and understand several tomes on the subject.

Done, IMHO.

> 2) Tasks can be automatically distributed among processors, so it
> solves the problems of (a) making python run faster (b) how to utilize
> multiprocessor systems.

Done.  The OS automatically maps subprocesses to other processors.

> 3) Tasks are cheap enough that I can make thousands of them, to solve
> modeling problems (in which I also lump games). This is really a
> solution to a cerain type of program complexity -- if I can just
> assign a task to each logical modeling unit, it makes such a system
> much easier to program.

Perhaps the suggested module should have a queue-oriented API.  Usage 
would look like this:

 import pyprocess
 queue = pyprocess.ProcessQueue(max_processes=4)
 task = queue.put('mypackage.mymodule', 'myfunc', arg1, arg2=5)

Then, you can create as many tasks as you like; parallelism will be 
limited to 4 concurrent tasks.  A variation of ProcessQueue might manage 
the concurrency limit automatically.

> 4) Tasks are "self-guarding," so they prevent other tasks from
> interfering with them. The only way tasks can communicate with each
> other is through some kind of formal mechanism (something queue-ish,
> I'd imagine).

Done.  Subprocesses have their own Python namespace.  Subprocesses 
receive messages through function calls and send messages by returning 
from functions.

> 5) Deadlock is prevented by default. I suspect livelock could still
> happen; I don't know if it's possible to eliminate that.

No locking is done at all.  (That makes me uneasy, though; have I just 
moved locking problems to the application developer?)

> 6) It's natural to make an object that is actor-ish. That is, this
> concurrency approach works intuitively with objects.

Anything pickleable is legal.

> 7) Complexity should be eliminated as much as possible. If it requires
> greater limitations on what you can do in exchange for a clear,
> simple, and safe programming model, that sounds pythonic to me. The
> way I see it, if we can't easily use tasks without getting into
> trouble, people won't use them. But if we have a model that allows
> people to (for example) make easy use of multiple processors, they
> wi

Re: [Python-Dev] C API doc fix

[M.-A. Lemburg]

Steven Bethard wrote:
> On 9/29/05, Robey Pointer <[EMAIL PROTECTED]> wrote:
> 
>>Yesterday I ran into a bug in the C API docs.  The top of this page:
>>
>> http://docs.python.org/api/unicodeObjects.html
>>
>>says:
>>
>>Py_UNICODE
>> This type represents a 16-bit unsigned storage type which is
>>used by Python internally as basis for holding Unicode ordinals. On
>>platforms where wchar_t is available and also has 16-bits, Py_UNICODE
>>is a typedef alias for wchar_t to enhance native platform
>>compatibility. On all other platforms, Py_UNICODE is a typedef alias
>>for unsigned short.
> 
> 
> I believe this is the same issue that was brought up in May[1].  My
> impression was that people could not agree on a documentation patch.
> 
> [1] http://www.python.org/dev/summary/2005-05-01_2005-05-15.html

The problem was not so much getting the documentation, but the
fact that Python builds as UCS4 version in case it finds a TCL
version built for UCS4 - contrary to the UCS2 default that is
documented.

If I ever get around to working on my Python todo list, this
is one of the things I'd like to restore - UCS4 should always
be an *explicit* compile time option due to the consequences that
go with it.

Unfortunately, many Linux distros nowadays build Python with UCS4 --
introducing yet another dimension to binary Python binaries.

In case you wonder, we now have these dimensions:

* Python version (2.3, 2.4, ...)
* OS version (Linux, Solaris, Windows, Mac OS X, ...)
* Architecture (PowerPC, x86, x86_64, SunSPARC, ...)
* Unicode variant (UCS2, UCS4)

Finding the right binary for his or her Python is getting
increasingly more complicated for the Python user (and we
are seeing this every day in support requests).

Something we might want to introduce in Python 2.5 is a short
identifier in the Python interpreter interactive startup printout
that provides easy to find values for all of the above dimensions.
It already includes Python version and OS name, but is missing
the other bits and pieces.

Perhaps a flag that fires up Python and runs platform.py
would help too.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
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] Pythonic concurrency

[Jonathan LaCour]

> I'd like to restart this discussion; I didn't mean to put forth active
> objects as "the" solution, only that it seems to be one of the better,
> more OO solutions that I've seen so far.

Thanks for doing this.  I think this is an issue that is going to be 
more and more important as Python continues to gain momentum, and I 
would love to see a PEP come out of this discussion.

> What I'd really like to figure out is the "pythonic" solution for
> concurrency. Guido and I got as far as agreeing that it wasn't
> threads.

Evaluating the situation is often confusing for Python beginners 
because:

1. You won't often find threads being the recommended solution
   for concurrency in Python.  There is some disagreement on
   this point, as the recent thread on the GIL reveals, but I
   think the point stands.

2. Multi-processing is often brought up as a good alternative to
   threading.

3. There are a decent number of built-in high level abstractions
   for threaded programming in Python (Queues, Thread objects,
   Lock objects, etc.) and plenty of documentation too.  These
   abstractions also make it relatively straightforward to make
   your code work on multiple platforms.

4. The only support for multi-processing is quite low-level, and
   can be single platform.  Forking isn't really an option on
   windows, and neither are named pipes.  Shared memory?  Forget
   it!  Sockets could be used, but thats a bit low-level.

Its really a shame.  There seems to be some consensus about 
multi-processing, but not a whole lot of interest in making it easier 
out of the box.  When it comes to multi-processing, batteries really 
_aren't_ included.  Sure, you have lead dioxide and some sulphuric 
acid, but you have to put them together to make your battery.  This 
isn't the end of the world, but I find it tedious, and I am sure it 
confuses and frustrates people new to Python.

> Here are my own criteria for what such a solution would look like:
>
> 1) It works by default, so that novices can use it without falling
> into the deep well of threading. That is, a program that you write
> using threading is broken by default, and the tool you have to fix it
> is "inspection." I want something that allows me to say "this is a
> task. Go." and have it work without the python programmer having to
> study and understand several tomes on the subject.
>
> 2) Tasks can be automatically distributed among processors, so it
> solves the problems of (a) making python run faster (b) how to utilize
> multiprocessor systems.
>
> 3) Tasks are cheap enough that I can make thousands of them, to solve
> modeling problems (in which I also lump games). This is really a
> solution to a cerain type of program complexity -- if I can just
> assign a task to each logical modeling unit, it makes such a system
> much easier to program.
>
> 4) Tasks are "self-guarding," so they prevent other tasks from
> interfering with them. The only way tasks can communicate with each
> other is through some kind of formal mechanism (something queue-ish,
> I'd imagine).
>
> 5) Deadlock is prevented by default. I suspect livelock could still
> happen; I don't know if it's possible to eliminate that.
>
> 6) It's natural to make an object that is actor-ish. That is, this
> concurrency approach works intuitively with objects.
>
> 7) Complexity should be eliminated as much as possible. If it requires
> greater limitations on what you can do in exchange for a clear,
> simple, and safe programming model, that sounds pythonic to me. The
> way I see it, if we can't easily use tasks without getting into
> trouble, people won't use them. But if we have a model that allows
> people to (for example) make easy use of multiple processors, they
> will use that approach and the (possible) extra overhead that you pay
> for the simplicity will be absorbed by the extra CPUs.
>
> 8) It should not exclude the possibility of mobile tasks/active
> objects, ideally with something relatively straightforward such as
> Linda-style tuple spaces.

This all sounds pretty brilliant to me, although even a small subset of 
what you define above would be totally adequate I think.  To me it 
breaks down simply into:

 1. The ability to spawn/create "tasks" (which are really processes)
easily, where tasks are isolated from each other.

 2. The ability to send a message into a task.  A formal queueing
mechanism would be nice, but the simple ability to send messages
is completely enough to roll your own queueing.

Preventing deadlock is hard.  Mobile tasks / active objects?  Getting 
way ahead of ourselves, I think.  Really, I just want those two things 
above, and I want it as a standard part of Python.

> One thing that occurs to me is that a number of items on this wish
> list may conflict with each other, which may require a different way
> of thinking about the problem. For example, it may require two
> 

Re: [Python-Dev] C API doc fix

[Bob Ippolito]

On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote:

> Perhaps a flag that fires up Python and runs platform.py
> would help too.

python -mplatform

-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/archive%40mail-archive.com

Re: [Python-Dev] C API doc fix

[Fredrik Lundh]

M.-A. Lemburg wrote:

> * Unicode variant (UCS2, UCS4)

don't forget the "Py_UNICODE is wchar_t" subvariant.

 



___
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] Adding a conditional expression in Py3.0

[Alexander J. Kozlovsky]

Guido van Rossum wrote:

> I did this for my favorite proposal, and ended up with the list shown
> further down below.
> 
> I think they all looks great!

I'm sorry for my bad English

IMHO, if condition is nontrivial, then the syntax:

expr1 if some complex condition else expr2

can be more hard to read as compared with:

if some complex condition then expr1 else expr2

In the second form visual comparison of expr1 and expr2 is simpler
because its adjacent placement. For example, in expression

'DO' if cmd == DO and flag == OK or x is None else 'DONT'

'DO' and 'DONT' visually divided and eyes must move there and back
for find the difference between them. As opposite, in expression

if cmd == DO and flag == OK or x is None then 'DO' else 'DONT'

it is very easy to determine what is possible expression output.
It is a bit more readable from my point of view



Best regards,
 Alexandermailto:[EMAIL PROTECTED]

___
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] Adding a conditional expression in Py3.0

[Michael Chermside]

[ongoing discussion of conditional expressions]

I waited until I had caught up on my reading before saying anything. Now I'll
express my opinion in a single posting then keep quiet unless I actually find I
have something novel to contribute (difficult in a topic that's been talked to
death 3 or 4 times in the past few years).

 * I am STRONGLY in favor of introducing a conditional expression in some
   form. The use of the "and-or" trick is proof enough to me that there is
   a need for it. I can marshall other arguments also, but they appear
   unnecessary.

 * The syntax to use is a place where we need a BDFL decision. Make the
   decision and we'll all agree and move on. Any decision would be better
   than an eternity of re-discovering old ideas again and again.

 * I think the two best options are
   trueval if cond else falseval
   and
   if cond then trueval else falseval
   The first has brevity in it's favor, and "cleverness" which might be
   an advantage or disadvantage depending on your point of view. The
   second has order-of-arguments in its favor. In either case, wise
   programmers will use parenthesees when it aids clarity (imagine
   "v1 if c else v2 + v3"). Whether we require parenthesees when the
   parser could disambiguate on its own is really up to Guido.

 * I prefer the second form ("if cond then trueval else falseval")
   because it puzzles _nobody_ at the expense of being slightly
   more wordy and less clever. But that's just one person's opinion.

Thanks Guido, for maintaining your patience in the face of this
discussion.

-- Michael Chermside

___
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 doc fix

[M.-A. Lemburg]

Bob Ippolito wrote:
> On Sep 29, 2005, at 3:53 PM, M.-A. Lemburg wrote:
> 
> 
>>Perhaps a flag that fires up Python and runs platform.py
>>would help too.
> 
> 
> python -mplatform

Cool :-)

Now we only need to add some more information to it (like e.g.
the Unicode variant).

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
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 doc fix

[M.-A. Lemburg]

Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
> 
> 
>>* Unicode variant (UCS2, UCS4)
> 
> 
> don't forget the "Py_UNICODE is wchar_t" subvariant.

True, but that's not relevant for binary compatibility of
Python package (at least not AFAIK).

UCS2 vs. UCS4 matters because the two versions use and expose
different C APIs and thus an extension written for UCS2 doesn't
run with a Python built for UCS4 and vice-versa.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Sep 29 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
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] Adding a conditional expression in Py3.0

[Terry Reedy]

"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> After all there's nothing wrong with and/or.

This is one reason 'no addition' got a relatively high rank in the vote.

Examples...
> telnet~1.py:'DO' if cmd == DO else 'DONT',
versuscmd == DO and 'DO' or 'DONT'

I still stronly prefer this order and even slightly prefer this form.  I 
might even prefer a complete inversion of the order: x else y if c
 'DO' else 'DONT' if cmd != DO
except that that does not chain at all well.

Terry J. Reedy



___
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] Adding a conditional expression in Py3.0

[Steve Holden]

Guido van Rossum wrote:
> On 9/29/05, Steve Holden <[EMAIL PROTECTED]> wrote:
> 
>>I would argue for mandatory parentheses around the expression, leaving
>>room later (probably after Guido is no longer around to be sick at the
>>site of it) for:
>>
>>def f(condition):
>> return something if condition # no else!
>> return somethingElse
>>
>>not-expecting-this-to-fly-ly y'rs  - steve
> 
> 
> Let me give you what you expect. If all the "X if C else Y" syntax
> does is prevent that atrocity from ever being introduced, it would be
> worth it. :)
> 
Well, fine. However, it does allow atrocities like

func(f for f in lst if f > -1 if f < 0 else +1)

I realise that any chosen syntax is subject to abuse, but a conditional 
expression in a (currently allowed) conditional context will be 
guaranteed obscure. Your original instinct to omit conditional 
expressions was right!

far-too-late-ly y'rs  - steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/

___
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] David Mertz on CA state e-voting panel

[Guido van Rossum]

http://yro.slashdot.org/yro/05/09/28/1955256.shtml?tid=103&tid=17&tid=219

Congratulations David! (Don't have his email.)

--
--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] PEP 350: Codetags

[Josiah Carlson]

Micah Elliott <[EMAIL PROTECTED]> wrote:
> Josiah> an unofficial spec is sufficient.  See koders.com and search
> Josiah> for 'fixme' to see some common variants.
> 
> But that's the problem -- there are already a bunch of "unofficial"
> specs, which don't serve much purpose as such.  It's a cool site.  I
> spent some time browsing and I do see a lot of codetags in use (many
> thousands in Python code alone; I'm not sure if the number represented
> strings or files).  But I'll argue that this just reinforces the need
> for an *official* spec/guideline, so that the tools can do something
> with them.

Defining a spec for code tags doesn't mean that people will start using
them.  Why?  Because it is a documentation spec.  From my experience,
documentation specs are only adhered to by the organizations (companies,
groups, etc.) which the code is produced by and for, and they generally
define the code specs for their organization.

Further, even if it becomes a spec, it doesn't guarantee implementation
in Python editors (for which you are shooting for). Take a wander
through current implementations of code tags in various editors to get a
feel for what they support.  I've read various posts about what code
tags could support, but not what editors which implement code tags
and/or its variants actually currently support; which is a better
indication of what people want than an informal survey via email of
python-dev, python-list, and/or the PEP submission process.

 - 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

[Python-Dev] Pythonic concurrency

[Jim Jewett]

Bruce Eckel wrote:

> 3) Tasks are cheap enough that I can make
> thousands of them, ...

> 4) Tasks are "self-guarding," so they prevent
> other tasks from interfering with them. The
> only way tasks can communicate with each
> other is through some kind of formal
> mechanism (something queue-ish,
> I'd imagine).

I think these two are the hardest to reconcile.

Shane Hathaway's suggestion starts from the
process end.

A new process isn't cheap.  Keeping the other
process' interpreter alive and feeding it more
requests through a queue just hides the
problem; you can't have more non-sequential
tasks than processors without restarting the
whole contention issue.  Even using sequential
tasks (similar to "import dummy_thread") lets
task1 mess up the builtins (or other library
modules) for future task2.  The more guards
you add, the heavier each task gets.

At the other end are generators; I think what
generators are missing is

(A)  You can't easily send them a message.

This can be solved by wrapping them in an
object, or (probably) by waiting until 2.5.

(B)  The programmer has to supply a scheduler.

This could be solved by a standard library module.

(C)  That scheduler is non-preemptive.  A single
greedy generator can starve all the others.

You can reduce the problem by scheduling
generators on more than one thread.

To really solve it would require language support.
That *might* be almost as simple as a new object
type that automatically yielded control every so often
(like threads).

(D)  Generators can interfere with each other unless
the programmer is careful to treat all externally visible
objects as immutable.

Again, it would require language support.  I also have
a vague feeling that fixing (C) or (D) might make the
other worse.

(E)  Generators are not reentrant.

I know you said that some restrictions are reasonable,
and this might fall into that category ... but I think this
becomes a problem as soon as Tasks can handle
more than one type of message, or can send delayed
replies to specific correspondents.  (To finish your
request, I need some more information...)

-jJ
___
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] Adding a conditional expression in Py3.0

[Guido van Rossum]

[Guido]
> > Let me give you what you expect. If all the "X if C else Y" syntax
> > does is prevent that atrocity from ever being introduced, it would be
> > worth it. :)

[Steve]
> Well, fine. However, it does allow atrocities like
>
> func(f for f in lst if f > -1 if f < 0 else +1)

No it doesn't! Inside an 'if' (of any flavor), further ifs have to be
nested. So you'd have to write

  func(f for f in lst if f > (-1 if f < 0 else +1))

or perhaps

  func(f for f in lst if (f > -1 if f < 0 else +1))

But I doubt you meant to write +1 where True could have sufficed. :)

An if-else expression has lower priority than anything else except
lambda; the expression

lambda x: x if x >= 0 else -x

is equivalent to

lambda x: (x if x >= 0 else -x)

> I realise that any chosen syntax is subject to abuse, but a conditional
> expression in a (currently allowed) conditional context will be
> guaranteed obscure. Your original instinct to omit conditional
> expressions was right!

Now you've pushed me over the edge. I've made up my mind now, "X if C
else Y" it will be. I hope to find time to implement it in Python 2.5.
Let it be as controversial as bool or @decorator, I don't care.

--
--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

[Python-Dev] [PATCH][BUG] Segmentation Fault in xml.dom.minidom.parse

[Evan Jones]

The following Python script causes Python 2.3, 2.4 and the latest CVS  
to crash with a Segmentation Fault:

import xml.dom.minidom
x = u'\nComment \xe7a va ? Tr\xe8s  
bien ?'
dom = xml.dom.minidom.parseString( x.encode( 'latin_1' ) )
print repr( dom.childNodes[0].localName )


The problem is that this XML document does not specify an encoding. In  
this case, minidom assumes that it is encoded in UTF-8. However, in  
fact it is encoded in Latin-1. My two line patch, in the SourceForge  
tracker at the URL below, causes this to raise a UnicodeDecodingError  
instead.

http://sourceforge.net/tracker/index.php? 
func=detail&aid=1309009&group_id=5470&atid=305470

Any chance that someone wants to commit this tiny two line fix? This  
might be the kind of fix that might be elegible to be backported to  
Python 2.4 as well. It passes "make test" on both my Linux system and  
my Mac. I've also attached a patch that adds this test case to  
test_minidom.py.

Thanks,

Evan Jones

--
Evan Jones
http://evanjones.ca/

___
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] Adding a conditional expression in Py3.0

[Greg Ewing]

Nick Coghlan wrote:

> i.e., it's 
> like an "or", only we're asking that the decision be made based on something 
> other than the truth value of the left hand operand.

Hmmm, then maybe it should be

   a or c if b

or perhaps

   a or, if b, c

:-)

-- 
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,  | A citizen of NewZealandCorp, a   |
Christchurch, New Zealand  | wholly-owned subsidiary of USA Inc.  |
[EMAIL PROTECTED]  +--+
___
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] Conditional Expression Resolution

[Guido van Rossum]

After a long discussion I've decided to add a shortcut conditional
expression to Python 2.5.

The syntax will be

A if C else B

This first evaluates C; if it is true, A is evaluated to give the
result, otherwise, B is evaluated to give the result.

The priorities will be such that you can write

x = A if C else B
x = lambda: A if C else B
x = A if C else B if D else E

But you'd have to write

if (A if C else B):
[x for x in seq if (A if C else B)]
A if (X if C else Y) else B
(A if C else B) if D else E

Note that all these are intentionally ugly. :)

In general, 'if' and 'else' bind less tight than everything except lambda.

We will adjust the syntax of what goes inside an 'if' to disallow
lambda; currently

if lambda: x:

is accepted but quite useless (it's always true) so this will be disallowed.

Flames, pleas to reconsider, etc., to /dev/null.

Congratulations gracefully accepted.

It's still my language! :-)

--
--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] Conditional Expression Resolution

[Neal Norwitz]

On 9/29/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> Flames, pleas to reconsider, etc., to /dev/null.
>
> Congratulations gracefully accepted.
>
> It's still my language! :-)

I don't like those options. :-)

How about this:
  Can someone update the PEP on conditional expressions to point to
this email and update the status, etc?

Thanks,
n
___
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 Expression Resolution

[Raymond Hettinger]

> How about this:
>   Can someone update the PEP on conditional expressions to point to
> this email and update the status, etc?

Already done.


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] Conditional Expression Resolution

[Steven Bethard]

On 9/29/05, Guido van Rossum wrote:
> After a long discussion I've decided to add a shortcut conditional
> expression to Python 2.5.
>
> The syntax will be
>
> A if C else B
>
[snip]
>
> Congratulations gracefully accepted.

Congratulations, and many thanks for making this decision before the
threads leaked into the next summary period. ;-)

STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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 Expression Resolution

[Delaney, Timothy (Tim)]

Guido van Rossum wrote:

> Congratulations gracefully accepted.

Whilst I'm not personally fond of the syntax, congratulations. Whilst I
don't feel this is a big step in the evolution of the language, it shuts
up a *very* frequently asked question (and opens up a new one ;)

Tim Delaney
___
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 Expression Resolution

[Christian Tismer]

Guido van Rossum wrote:

...

> Flames, pleas to reconsider, etc., to /dev/null.
> 
> Congratulations gracefully accepted.

Congratulations for a clear decision!

Personally, I would have preferred a "no, never in my life"
alternative response slightly more, but a clear say is better than
endless discussions about something as relevant as syntax.

My canned reply, tailored to fit into the set of accepted
answers reduces to "Thank you so much :-) ".

> It's still my language! :-)

Self-inconfidence alert! You would never need to say this if you
not felt like a bot. Please shut down and get adjusted.
Guidos don't say that. :-)

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  337 open ( +0) /  2947 closed ( +6) /  3284 total ( +6)
Bugs:  912 open ( +4) /  5278 closed (+16) /  6190 total (+20)
RFE :  195 open ( +1) /   187 closed ( +0) /   382 total ( +1)

New / Reopened Patches
__

fix for distutils "upload" command  (2005-09-23)
   http://python.org/sf/1299675  opened by  Richard Jones

xdrlib.py: pack_fstring() did not use null bytes for padding  (2005-09-23)
CLOSED http://python.org/sf/1300515  opened by  Don Quijote

desktop module (providing startfile as open, all platforms)  (2005-09-23)
   http://python.org/sf/1301512  opened by  Paul Boddie

Update documentation for __builtins__  (2005-09-24)
   http://python.org/sf/1303595  opened by  Collin Winter

Strobe Timer for guis  (2005-09-26)
   http://python.org/sf/1304895  opened by  Brett Rosen

pyexpat.c: Two line fix for decoding crash  (2005-09-29)
   http://python.org/sf/1309009  opened by  Evan Jones

Patches Closed
__

cjkcodecs does not initialize type pointer  (2005-09-20)
   http://python.org/sf/1297028  closed by  nnorwitz

xdrlib.py: pack_fstring() did not use null bytes for padding  (2005-09-23)
   http://python.org/sf/1300515  closed by  birkenfeld

vendor-packages directory.  (2005-09-22)
   http://python.org/sf/1298835  closed by  richburridge

PyOS_InputHook inconsistency on Windows  (2004-10-19)
   http://python.org/sf/1049855  closed by  loewis

FreeBSD 5.3 and upward has thread-safe getaddrinfo(3)  (2005-09-13)
   http://python.org/sf/1288833  closed by  perky

use LIST_APPEND opcode for X.append() method calls  (2005-09-16)
   http://python.org/sf/1292625  closed by  nnorwitz

New / Reopened Bugs
___

A command history for the idle interactive shell  (2005-09-24)
   http://python.org/sf/1302267  opened by  Björn Lindqvist

2.4.1 windows MSI has no _socket  (2005-09-24)
   http://python.org/sf/1302793  opened by  IamPaul

SSL-ed sockets don't close correct?  (2004-06-24)
   http://python.org/sf/978833  reopened by  kxroberto

Bypassing __dict__ readonlyness  (2005-09-24)
   http://python.org/sf/1303614  opened by  Armin Rigo

traceback on trying to load a file  (2005-09-24)
   http://python.org/sf/1303673  opened by  nanotube

Extended slice bug (or feature?)  (2005-09-25)
CLOSED http://python.org/sf/1303928  reopened by  mwh

Extended slice bug (or feature?)  (2005-09-25)
CLOSED http://python.org/sf/1303928  opened by  David M. Beazley

2.3.5 configure / make infinite loop  (2005-09-25)
   http://python.org/sf/1304179  opened by  Michael Schwartz

windows unicode write is messing up the EOL.  (2005-09-27)
CLOSED http://python.org/sf/1305706  opened by  Istvan Visegradi

Syntax error in Python Library Reference, 6.1.4. Files ...  (2005-09-27)
CLOSED http://python.org/sf/1306043  opened by  Alexander Schliep

Python 2.4.2c1 fails to build for 64-bit Solaris 9/10  (2005-09-27)
CLOSED http://python.org/sf/1306211  opened by  John Stone

Add 64-bit Solaris 9 build instructions to README  (2005-09-27)
   http://python.org/sf/1306248  opened by  John Stone

Python 2.4.2c1 fails to build on 64-bit Solaris 10  (2005-09-27)
   http://python.org/sf/1306253  opened by  John Stone

PyString_AsStringAndSize() return value documented wroing  (2005-09-28)
CLOSED http://python.org/sf/1306449  opened by  Gregory Bond

compile() converts "filename" parameter to StringType  (2005-09-28)
   http://python.org/sf/1306484  opened by  Vágvölgyi Attila

Augmented assigment to mutable objects in tuples fail  (2005-09-28)
CLOSED http://python.org/sf/1306777  opened by  Mattias Engdegård

=, not =  (2005-09-28)
CLOSED http://python.org/sf/1307188  opened by  Davide Andrea

Datagram Socket Timeouts  (2005-09-28)
   http://python.org/sf/1307357  opened by  Tom Vrankar

subprocess.Popen locks on Cygwin  (2005-09-29)
   http://python.org/sf/1307798  opened by  Jacek Poplawski

PCbuild vcproj project files need a cleanup  (2005-09-29)
   http://python.org/sf/1307806  opened by  Adal Chiriliuc

Unsatisfied symbols: _PyGILState_NoteThreadState (code)  (2005-09-29)
   http://python.org/sf/1307978  opened by  Goetz Isenmann

Datagram Socket Timeouts  (2005-09-29)
   http://python.org/sf/1308042  opened by  Tom Vrankar

Py_BuildValue (C/API): "K" format  (2005-09-29)
CLOSED http://python.org/sf/1308740  opened by  Yair Chuchem

Bugs Closed
___

Incorrect return type for search() method  (2005-09-20)
   http://python.org/sf/1297059  closed by  nnorwitz

build fails on Solaris 10 for Objects/complexobject.c  (2005-09-22)
   http://python.org/sf/1299187  closed by  nnorwitz

test_ioctl fails  (2003-07-26)
   http://python.org/sf/777867  closed by  birkenfeld

test_ioctl fails  (2003-07-31)
   http://python.org/sf/780576  closed by  birkenfeld

subprocesss module retains older license header  (2005-02-17)
   http:/

Re: [Python-Dev] [PATCH][BUG] Segmentation Fault in xml.dom.minidom.parse

[Neal Norwitz]

On 9/29/05, Evan Jones <[EMAIL PROTECTED]> wrote:
>
> Any chance that someone wants to commit this tiny two line fix?

That's reallly not the question you *want* to be asking.  :-)

> This might be the kind of fix that might be elegible to be backported to
> Python 2.4 as well. It passes "make test" on both my Linux system and
> my Mac. I've also attached a patch that adds this test case to
> test_minidom.py.

There was a problem your patch exposed.  I fixed that too.  I even
backported it.

Thanks,
n
___
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] Adding a conditional expression in Py3.0

[Steve Holden]

Guido van Rossum wrote:
> [Guido]
> 
>>>Let me give you what you expect. If all the "X if C else Y" syntax
>>>does is prevent that atrocity from ever being introduced, it would be
>>>worth it. :)
> 
> 
> [Steve]
> 
>>Well, fine. However, it does allow atrocities like
>>
>>func(f for f in lst if f > -1 if f < 0 else +1)
> 
> 
> No it doesn't! Inside an 'if' (of any flavor), further ifs have to be
> nested. So you'd have to write
> 
>   func(f for f in lst if f > (-1 if f < 0 else +1))
> 
> or perhaps
> 
>   func(f for f in lst if (f > -1 if f < 0 else +1))
> 
> But I doubt you meant to write +1 where True could have sufficed. :)
> 
:)

All that said, inside an "if" is hardly the best place for a conditional 
of any kind. Clearly such usage can go down as abuse.

> An if-else expression has lower priority than anything else except
> lambda; the expression
> 
> lambda x: x if x >= 0 else -x
> 
> is equivalent to
> 
> lambda x: (x if x >= 0 else -x)
> 
That's about the only way it would make sense, I suppose.
> 
>>I realise that any chosen syntax is subject to abuse, but a conditional
>>expression in a (currently allowed) conditional context will be
>>guaranteed obscure. Your original instinct to omit conditional
>>expressions was right!
> 
> 
> Now you've pushed me over the edge. I've made up my mind now, "X if C
> else Y" it will be. I hope to find time to implement it in Python 2.5.
> Let it be as controversial as bool or @decorator, I don't care.
> 
Not before time, either. If this ends the discussion then I'll consider 
I've done everyone a favour. Sometimes no decision is worse than the 
wrong decision ;-).

regards
  Steve
-- 
Steve Holden   +44 150 684 7255  +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006  www.python.org/pycon/
___
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