[Python-Dev] subprocess.CalledProcessError.errno (#1223937)

[Peter Åstrand]

I intend to fix bug #1223937: subprocess.py abuse of errno. I thought this was 
going to to tricky, to maintain backwards compatibility, but then I realized 
that check_call() and CalledProcessError() are not available in any released 
version of Python, so I guess it's safe to change them.


See http://www.python.org/sf?id=1223937 for my suggested patch. Any chance this 
can go into 2.5? Yeah, I know I'm late :)


Regards,
--
Peter Åstrand   ThinLinc Chief Developer
Cendio  http://www.cendio.se
Teknikringen 3
583 30 LinköpingPhone: +46-13-21 46 00___
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] subprocess.CalledProcessError.errno (#1223937)

[Fredrik Lundh]

Peter Åstrand wrote:

> I intend to fix bug #1223937: subprocess.py abuse of errno. I thought 
> this was going to to tricky, to maintain backwards compatibility, but 
> then I realized that check_call() and CalledProcessError() are not 
> available in any released version of Python, so I guess it's safe to 
> change them.
> 
> See http://www.python.org/sf?id=1223937 for my suggested patch. Any 
> chance this can go into 2.5? Yeah, I know I'm late :)

that's up to Anthony to decide, but I'd say this this qualifies as a bug 
fix.



___
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] Explicit Lexical Scoping (pre-PEP?)

[Fuzzyman]

Talin wrote:

>Ka-Ping Yee wrote:
>  
>
>>On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote:
>>
>>
>>
>>>I think Talin's got a point though.  It seems hard to find one short English
>>>word that captures the essence of the desired behavior.  None of the words
>>>in his list seem strongly suggestive of the meaning to me.  I suspect that
>>>means one's ultimately as good (or as bad) as the rest.
>>>  
>>>
>>What's wrong with "nonlocal"?  I don't think i've seen an argument
>>against that one so far (from Talin or others).
>>
>>
>
>Well, I just think that a fix for "an aesthetic wart" should be, well, 
>aesthetic :)
>
>I also think that it won't be a complete disaster if we do nothing at 
>all - there *are* existing ways to deal with this problem; there are 
>even some which aren't hackish and non-obvious. For example, its easy 
>enough to create an object which acts as an artificial scope:
>
>def x():
>   scope = object()
>   scope.x = 1
>   def y():
>  scope.x = 2
>
>To my mind, the above code looks about as elegant and efficient as most 
>of the proposals put forward so far, and it already works.
>
>How much are we really saving here by building this feature into the 
>language?
>  
>
 >>> def x():
  ...:scope = object()
  ...:scope.x = 1
  ...:def y():
  ...:scope.x = 2
>>> x()
---
exceptions.AttributeErrorTraceback (most
recent call
 last)

I've often found it a nuisance that you can't instantiate an 'object',
to use as a mutable 'namespace', but instead have to define an arbitrary
empty class.

What happened to the 'namespace' proposal ?

Michael Foord
http://www.voidspace.org.uk/python/index.shtml

>-- Talin
>___
>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/fuzzyman%40voidspace.org.uk
>
>  
>

___
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] User's complaints

[Michael Hudson]

"A.M. Kuchling" <[EMAIL PROTECTED]> writes:

> On Mon, Jul 10, 2006 at 05:13:53PM +0200, Armin Rigo wrote:
>> didn't draw much applause.  It certainly gave me the impression that
>> many changes in Python are advocated and welcomed by only a small
>> fraction of users.
>
> The benefits of changes are usually clear, but I don't think the costs
> of changes are fully assessed.  python-dev considers the cost of
> changes to CPython's implementation, but I don't think the cost
> changes to Jython, IronPython, or PyPy are taken into account here.

I don't want to attempt to speak for Armin, but I don't think that was
quite the point he was trying to make.  The cost of implementation
isn't really that high -- most of the changes from 2.3 to 2.4 were
implemented for PyPy in about a week and we have implementations of
most of the 2.5 features already, and you can also consider the
decorators discussion where each of the proposed syntaxes had solid
tested implementations.

At least from my POV, the cost of bad design, whether through simple
lack of sufficient thought or aggregation of features into cruft, is
much much higher.

> PyPy probably has enough representatives here who would squawk if
> something was difficult, but I don't think Jython or IronPython do.

People implementing Python should accept the fact that Python is a
changing language, IMHO.

> I think if we assessed those costs fully, the bar for changes to the
> language would be a good deal higher.

I think if you assessed these other costs fully, the bar would be
higher still.

Cheers,
mwh

-- 
  This is the fixed point problem again; since all some implementors
  do is implement the compiler and libraries for compiler writing, the
  language becomes good at writing compilers and not much else!
 -- Brian Rogoff, comp.lang.functional
___
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] Explicit Lexical Scoping (pre-PEP?)

[K.S.Sreeram]

Talin wrote:
> def x():
>scope = object()
>scope.x = 1
>def y():
>   scope.x = 2

'object' doesn't let you set custom attributes.
Here's what I normally use in my code...

class Data : pass

def x() :
d = Data()
d.x = 1
def y() :
d.x += 1


Regards
Sreeram




signature.asc
Description: OpenPGP digital signature
___
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] Explicit Lexical Scoping (pre-PEP?)

[Nick Coghlan]

Fuzzyman wrote:
> I've often found it a nuisance that you can't instantiate an 'object',
> to use as a mutable 'namespace', but instead have to define an arbitrary
> empty class.
> 
> What happened to the 'namespace' proposal ?

The code and the pre-PEP [1] are still out there, but Carlos, Steve and I all 
got distracted by other things. It really needs to go back to c.l.p to thrash 
out some of the name collision prblems (e.g. should *all* access to methods, 
even special methods, be via type(x)?).

Cheers,
Nick.

[1] http://namespace.python-hosting.com/wiki/NamespacePep

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

[Talin]

I thought a little bit more about Guido's comment that you can hide 
Python objects in a C wrapper class. However, as I was trying to sleep, 
I realized that you don't even need C to do it.

The trick is to store the object reference as a closure variable. 
Assuming that there's no mechanism to directly access such variables, 
you can effectively have 'private' variables.

Here's an pure-Python implementation of a wrapper that restricts access 
to all class members except those marked with the 'public' decorator. 
Note in the test cases below that even '__class__' and '__dict__' are 
inaccessible.
--

# Exception to throw when we violate restrictions
class GuardException( Exception ): pass

# Decorator function
def public(func):
 func.f_public = True
 return func

# Wrapper function
def guard(content):
 class Guard(object):
 def __getattribute__(self, name):
 # This will throw an AttributeException if the
 # attribute doesn't exist, which is what
 # we want.
 attr = object.__getattribute__(content,name)
 if hasattr( attr, 'im_func' ):
 if hasattr( attr.im_func, 'f_public' ):
 # We can't return the bound method directly,
 # instead we create a proxy for it.
 def proxy_attr( *args, **kwargs ):
 return attr( *args, **kwargs )
 return proxy_attr

 # Attribute exists but has no proxy
 raise GuardException( name )

 return Guard()

# Test class
class Test(object):
 def __init__(self,name):
 self.name = name

 @public
 def get_name(self):
 return self.name

 def set_name(self,name):
 self,name = name

# Test objects. First is unwrapped, second is wrapped.
t1 = Test("alpha")
t2 = guard(Test("beta"))

# These functions work correctly
print t1.name
print t2.get_name()

# This gets AttributeError because there's no such attribute
print t2.unk()

# These generate GuardException
print t2.set_name()
print t2.__dict__
print t2.__class__
print t2.name

--

-- Talin
___
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] Doctest and Footnotes

[Benji York]

Phillip J. Eby wrote:
> It would be nice if tracebacks in the footnote show the invoking context

Yep.  Someone (Jim Fulton I think) had suggested that to me.  I'll look 
into it.

> My other thought would be that having a patch that works against the 2.5 
> version of doctest would be good

My intent is to update zope.testing to the 2.5 version of doctest and 
generate a new patch against that.

It would be even better if there were a stand-alone release of doctest 
instead, or (another Jim suggestion) if doctest were made extensible.  I 
have another doctest/ReST idea I'd like to try some time (using ReST 
tables for FIT), so if there's interest perhaps I'll try my hand at a 
plugin system of some sort. (wish I could use zope.component :)
--
Benji York

___
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] 2.5 and beyond

[Gareth McCaughan]

> I can say it stronger. Any resemblance between Python and Scheme or
> Lisp is purely a coincidence. Neither language is in Python's
> ancestry, at least not explicitly; I'd never used or tried to learn
> Scheme when I started Python (still haven't) and my Lisp experience
> was limited to copying Emacs startup code from friends (still is).

Python resembles Lisp like an octopus eye resembles a mammalian eye:
they have lots in common because they're both pretty good solutions
to similar problems. Deciding whether it's Python or Lisp that has
the retina fitted back-to-front is left as an exercise for the reader.

-- 
g

___
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] [slighly OT] Native speakers and hurting brains

[Boris Borcic]

Greg Ewing wrote:
> Boris Borcic wrote:
> 
>> I believe that in this case native linguistic intuition made the decision...
> 
> The reason has nothing to do with language. Guido didn't
> want sum() to become an attractive nuisance by *appearing*
> to be an obvious way of joining a list of strings, while
> actually being a very inefficient way of doing that.

sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way 
of 
chaining strings in a list (without actually being one).

> Considerable effort was put into trying to make sum()
> smart enough to detect when you were using it on a
> list of strings and do "".join behind the scenes, but
> Guido decided in the end that it wasn't worth the
> trouble, given that he only ever intended sum() to
> be used on numbers in the first place.

That's not quite conform to the record. According to py-dev archives it 
happened 
on April 2003 with a thread "Fwd: summing a bunch of numbers (or "whatevers")" 
initiated by Alex Martelli where he actually proposed a working implementation 
of sum() in C, that did short-circuit the case of strings to ''.join. That was 
Sat 19th of April.

Debate ensued, and by late Sunday 20th around 11PM;, the honorable author of 
the 
Zen of Python had killed that use case for sum() with "sum(sequence_of_strings) 
hurts my brain". (Hello Tim, so what about  < sqrt(':(') >  ?)

Guido's first intervention in the thread was the next morning, and the two very 
first lines of his intervention where :

"OK, let me summarize and pronounce.

  sum(sequence_of_strings) is out"

I admit that there is a step of arguable interpretation from these recorded 
facts to my diagnostic, but the latter is compatible with the facts. Your 
version otoh looks more robust in the role of eg creation myth.

Best Regards, Boris Borcic
--
"assert 304 in 340343, P424D15E_M15M47CH"


___
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] [slighly OT] Native speakers and hurting brains

[Fredrik Lundh]

Boris Borcic wrote:

>>> I believe that in this case native linguistic intuition made the decision...
>>
>> The reason has nothing to do with language. Guido didn't
>> want sum() to become an attractive nuisance by *appearing*
>> to be an obvious way of joining a list of strings, while
>> actually being a very inefficient way of doing that.
>
> sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way 
> of
> chaining strings in a list (without actually being one).

in what language the word "sum" an appropriate synonym for "concatenate" ?

 



___
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] [slighly OT] Native speakers and hurting brains

[Gareth McCaughan]

(Attention conservation notice: the following is concerned almost entirely
with exegesis of an old python-dev thread. Those interested in improving Python
and not in history and exegesis should probably ignore it.)

On Tuesday 2006-07-11 13:43, Boris Borcic wrote:

> >> I believe that in this case native linguistic intuition made the 
> >> decision...
> > 
> > The reason has nothing to do with language. Guido didn't
> > want sum() to become an attractive nuisance by *appearing*
> > to be an obvious way of joining a list of strings, while
> > actually being a very inefficient way of doing that.
> 
> sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way 
> of 
> chaining strings in a list (without actually being one).

It is a *short-term* attractive nuisance; anyone who tries it
will quickly find that it can't be used to "sum" strings;
whereas if this functionality of sum() had been retained
then users would much more readily have been led to use it
*and leave it in their programs*, to the detriment of their
efficiency.

> > Considerable effort was put into trying to make sum()
> > smart enough to detect when you were using it on a
> > list of strings and do "".join behind the scenes, but
> > Guido decided in the end that it wasn't worth the
> > trouble, given that he only ever intended sum() to
> > be used on numbers in the first place.
> 
> That's not quite conform to the record. According to py-dev archives it 
> happened 
> on April 2003 with a thread "Fwd: summing a bunch of numbers (or 
> "whatevers")" 
> initiated by Alex Martelli where he actually proposed a working 
> implementation 
> of sum() in C, that did short-circuit the case of strings to ''.join. That 
> was 
> Sat 19th of April.
> 
> Debate ensued, and by late Sunday 20th around 11PM;, the honorable author of 
> the 
> Zen of Python had killed that use case for sum() with 
> "sum(sequence_of_strings) 
> hurts my brain". (Hello Tim, so what about  < sqrt(':(') >  ?)

Hardly "killed", since discussion of sum(stringseq) continued after
Tim's comment, and since Tim was neither the only, nor the first, nor
(I think) the last, person to object to sum(stringseq).

> Guido's first intervention in the thread was the next morning, and the two 
> very 
> first lines of his intervention where :
> 
> "OK, let me summarize and pronounce.
> 
>   sum(sequence_of_strings) is out"
> 
> I admit that there is a step of arguable interpretation from these recorded 
> facts to my diagnostic, but the latter is compatible with the facts. Your 
> version otoh looks more robust in the role of eg creation myth.

Your interpretation is only "compatible with the facts" by means
of the hypothesis that Guido, despite saying "OK, let me summarize
and pronounce" (which, incidentally, was the *actual* opening of
that message, which was not Guido's first intervention in the
thread, but who cares about facts?), had only read Tim Peters's
message and not the rest of the thread. Including, for instance,
one of the last messages before Guido's, from Alex, reporting that
his sum() concatenated strings twice as slowly as ''.join. It also
requires one to ignore the fact that Guido said (in that same
message that you described as his "first intervention")

  |   OTOH if we provide *any* way of providing a
  | different starting point, some creative newbie is going to use
  | sum(list_of_strings, "") instead of "".join(), and be hurt by the
  | performance months later.

and the fact that in Guido's *actual* "first intervention" he
said that he found sum(stringseq) "weird" and would continue to
use ''.join. (Remark: Guido is not a native speaker of English,
though he's a very competent one.) For that matter, Tim's
comment about sum(stringseq) hurting his brain was in direct
response to another part of that same message from Guido in
which he said that "the name sum() strongly suggests that it's
summing up numbers". (Remark: Guido still isn't a native speaker
of English.)

Perhaps the fact that "sum" isn't a natural English term for
concatenation of strings -- which, indeed, it isn't -- was one
of his reasons; it demonstrably wasn't the only one; and it
seems to have been the non-native speaker Guido himself who
introduced that consideration to the discussion.

It appears to me that your interpretation is difficult to reconcile
with the facts and is based on an incorrect and narrow reading of the
original texts. What was that you were saying about creation myths?

(I agree that Greg's interpretation is also not well supported
by that thread; I don't know whether Guido later said anything
that would determine how much truth there is in it. Since sum()
was Alex Martelli's invention, it seems unlikely that Greg's
quite right.)

-- 
g

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

Re: [Python-Dev] [slighly OT] Native speakers and hurting brains

[Boris Borcic]

Gareth McCaughan wrote:
> (Attention conservation notice: the following is concerned almost entirely
> with exegesis of an old python-dev thread. Those interested in improving 
> Python
> and not in history and exegesis should probably ignore it.)
> 
> On Tuesday 2006-07-11 13:43, Boris Borcic wrote:
> 
 I believe that in this case native linguistic intuition made the 
 decision...
>>> The reason has nothing to do with language. Guido didn't
>>> want sum() to become an attractive nuisance by *appearing*
>>> to be an obvious way of joining a list of strings, while
>>> actually being a very inefficient way of doing that.
>> sum() *is* exactly an attractive nuisance by *appearing* to be an obvious 
>> way of 
>> chaining strings in a list (without actually being one).
> 
> It is a *short-term* attractive nuisance; anyone who tries it
> will quickly find that it can't be used to "sum" strings;
> whereas if this functionality of sum() had been retained
> then users would much more readily have been led to use it
> *and leave it in their programs*, to the detriment of their
> efficiency.
> 
>>> Considerable effort was put into trying to make sum()
>>> smart enough to detect when you were using it on a
>>> list of strings and do "".join behind the scenes, but
>>> Guido decided in the end that it wasn't worth the
>>> trouble, given that he only ever intended sum() to
>>> be used on numbers in the first place.
>> That's not quite conform to the record. According to py-dev archives it 
>> happened 
>> on April 2003 with a thread "Fwd: summing a bunch of numbers (or 
>> "whatevers")" 
>> initiated by Alex Martelli where he actually proposed a working 
>> implementation 
>> of sum() in C, that did short-circuit the case of strings to ''.join. That 
>> was 
>> Sat 19th of April.
>>
>> Debate ensued, and by late Sunday 20th around 11PM;, the honorable author of 
>> the 
>> Zen of Python had killed that use case for sum() with 
>> "sum(sequence_of_strings) 
>> hurts my brain". (Hello Tim, so what about  < sqrt(':(') >  ?)
> 
> Hardly "killed", since discussion of sum(stringseq) continued after
> Tim's comment, and since Tim was neither the only, nor the first, nor
> (I think) the last, person to object to sum(stringseq).
> 
>> Guido's first intervention in the thread was the next morning, and the two 
>> very 
>> first lines of his intervention where :
>>
>> "OK, let me summarize and pronounce.
>>
>>   sum(sequence_of_strings) is out"
>>
>> I admit that there is a step of arguable interpretation from these recorded 
>> facts to my diagnostic, but the latter is compatible with the facts. Your 
>> version otoh looks more robust in the role of eg creation myth.
> 
> Your interpretation is only "compatible with the facts" by means
> of the hypothesis that Guido, despite saying "OK, let me summarize
> and pronounce" (which, incidentally, was the *actual* opening of
> that message, which was not Guido's first intervention in the
> thread, but who cares about facts?), had only read Tim Peters's
> message and not the rest of the thread. Including, for instance,
> one of the last messages before Guido's, from Alex, reporting that
> his sum() concatenated strings twice as slowly as ''.join. It also
> requires one to ignore the fact that Guido said (in that same
> message that you described as his "first intervention")
> 
>   |   OTOH if we provide *any* way of providing a
>   | different starting point, some creative newbie is going to use
>   | sum(list_of_strings, "") instead of "".join(), and be hurt by the
>   | performance months later.
> 
> and the fact that in Guido's *actual* "first intervention" he
> said that he found sum(stringseq) "weird" and would continue to
> use ''.join. (Remark: Guido is not a native speaker of English,
> though he's a very competent one.) For that matter, Tim's
> comment about sum(stringseq) hurting his brain was in direct
> response to another part of that same message from Guido in
> which he said that "the name sum() strongly suggests that it's
> summing up numbers". (Remark: Guido still isn't a native speaker
> of English.)
> 
> Perhaps the fact that "sum" isn't a natural English term for
> concatenation of strings -- which, indeed, it isn't -- was one
> of his reasons; it demonstrably wasn't the only one; and it
> seems to have been the non-native speaker Guido himself who
> introduced that consideration to the discussion.
> 
> It appears to me that your interpretation is difficult to reconcile
> with the facts and is based on an incorrect and narrow reading of the
> original texts. What was that you were saying about creation myths?
> 
> (I agree that Greg's interpretation is also not well supported
> by that thread; I don't know whether Guido later said anything
> that would determine how much truth there is in it. Since sum()
> was Alex Martelli's invention, it seems unlikely that Greg's
> quite right.)
> 

___
Py

Re: [Python-Dev] [slighly OT] Native speakers and hurting brains

[Boris Borcic]

I wish to apologize for mistakenly pushing the "send" button on an untouched 
copy of Gereth McGaughan's reply, in the case my early cancel at gmane did not 
stop the propagation.

I'll profit just to add (bringing this to a conclusion)

Gareth McCaughan wrote:
> (...was not Guido's first intervention in the
> thread, but who cares about facts?)

I do, and I stand corrected.

Best regards, Boris Borcic
--
"On naît tous les mètres du même monde"

___
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] urllib.quote and unicode bug resuscitation attempt

[Stefan Rank]

Hi,

urllib.quote fails on unicode strings and in an unhelpful way::

   Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] 
on win32
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import urllib
   >>> urllib.quote('a\xf1a')
   'a%F1a'
   >>> urllib.quote(u'ana')
   'ana'
   >>> urllib.quote(u'a\xf1a')
   Traceback (most recent call last):
 File "", line 1, in ?
 File "C:\Python24\lib\urllib.py", line 1117, in quote
   res = map(safe_map.__getitem__, s)
   KeyError: u'\xf1'

There is a (closed) tracker item, dated 2000-10-12,
http://sourceforge.net/tracker/?group_id=5470&atid=105470&aid=216716&func=detail
and there was a note added to PEP-42 by Guido.

According to a message I found on quixote-users,
http://mail.mems-exchange.org/durusmail/quixote-users/5363/
it might have worked prior to 2.4.2.
(I guess that this changed because of ascii now being the default encoding?)

BTW, a patch by rhettinger from 8 months or so ago allows urllib.unquote 
to operate transparently on unicode strings::

   >>> urllib.unquote('a%F1a')
   'a\xf1a'
   >>> urllib.unquote(u'a%F1a')
   u'a\xf1a'

I suggest to add (after 2.5 I assume) one of the following to the 
beginning of urllib.quote to either fail early and consistently on 
unicode arguments and improve the error message::

   if isinstance(s, unicode):
   raise TypeError("quote needs a byte string argument, not unicode,"
   " use `argument.encode('utf-8')` first.")

or to do The Right Thing (tm), which is utf-8 encoding::

   if isinstance(s, unicode):
   s = s.encode('utf-8')

as suggested in
http://www.w3.org/International/O-URL-code.html
and rfc3986.

cheers,
stefan

___
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] [slighly OT] Native speakers and hurting brains

[Boris Borcic]

Fredrik Lundh wrote:
> 
> in what language the word "sum" an appropriate synonym for "concatenate" ?

any that admits a+b to mean ''.join([a,b]), I'd say.

- BB

___
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] [slighly OT] Native speakers and hurting brains

[Fredrik Lundh]

Boris Borcic wrote:

>> in what language [is] the word "sum" an appropriate synonym for 
>> "concatenate" ?
>
> any that admits a+b to mean ''.join([a,b]), I'd say.

and what human language would that be ?

 



___
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] urllib.quote and unicode bug resuscitation attempt

[skip]

Stefan> According to a message I found on quixote-users,
Stefan> http://mail.mems-exchange.org/durusmail/quixote-users/5363/ it
Stefan> might have worked prior to 2.4.2.

Confirmed with 2.3.5.

Stefan>if isinstance(s, unicode):
Stefan>s = s.encode('utf-8')

Stefan> as suggested in
Stefan> http://www.w3.org/International/O-URL-code.html
Stefan> and rfc3986.

Seems like the right way to do it to me.

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] Explicit Lexical Scoping (pre-PEP?)

[Robin Bryce]

outbound x = 1
x = 2

evaluating using Jeremy Hilton's' list:

1. is a real word
2. For me - in python - it would mean: Is found in 'outer' scope and
is already bound.
  And the literal meaning of 'outbound 'headed away' [1] is pretty
darn close to what I mean when I spell the usual mutables kluge.

3 statement is positive form
4. I like it

could not find a use of outbound in python source (2.4.3)

[1] http://dictionary.reference.com/search?q=outbound


Robin
___
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] Explicit Lexical Scoping (pre-PEP?)

[Fuzzyman]

Robin Bryce wrote:

>outbound x = 1
>  
>
FWINW, to me 'nonlocal' clearly and immediately tells you what you need
to know about the variable.

'outbound' has no programming associations for me (it makes me think of
'outward bound' and roaming the great outdoors). So negative or not I'm
+1 on nonlocal if we really need this... (Hey, and I'm a native.)

Michael Foord
http://www.voidspace.org.uk/python/index.shtml


>x = 2
>
>evaluating using Jeremy Hilton's' list:
>
>1. is a real word
>2. For me - in python - it would mean: Is found in 'outer' scope and
>is already bound.
>  And the literal meaning of 'outbound 'headed away' [1] is pretty
>darn close to what I mean when I spell the usual mutables kluge.
>
>3 statement is positive form
>4. I like it
>
>could not find a use of outbound in python source (2.4.3)
>
>[1] http://dictionary.reference.com/search?q=outbound
>
>
>Robin
>___
>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/fuzzyman%40voidspace.org.uk
>
>  
>

___
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] Capabilities / Restricted Execution

[Phillip J. Eby]

At 03:36 AM 7/11/2006 -0700, Talin wrote:
>I thought a little bit more about Guido's comment that you can hide
>Python objects in a C wrapper class. However, as I was trying to sleep,
>I realized that you don't even need C to do it.
>
>The trick is to store the object reference as a closure variable.
>Assuming that there's no mechanism to directly access such variables,
>you can effectively have 'private' variables.

A function's func_closure contains cell objects that hold the 
variables.  These are readable if you can set the func_closure of some 
function of your own.  If the overall plan includes the ability to restrict 
func_closure setting (or reading) in a restricted interpreter, then you 
might be okay.

___
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] Subject: RELEASED Python 2.5 (beta 2)

[Anthony Baxter]

On behalf of the Python development team and the Python
community, I'm happy to announce the second BETA release
of Python 2.5.

This is an *beta* release of Python 2.5. As such, it is not
suitable for a production environment. It is being released
to solicit feedback and hopefully discover bugs, as well as
allowing you to determine how changes in 2.5 might impact
you. If you find things broken or incorrect, please log a
bug on Sourceforge.

In particular, note that changes to improve Python's support
of 64 bit systems might require authors of C extensions
to change their code. More information (as well as source
distributions and Windows installers) are available from the
2.5 website:

http://www.python.org/2.5/

A Universal Mac OSX Installer will be available shortly - in
the meantime, Mac users can build from the source tarballs.

Since the first beta, a large number of bug fixes have been
made to Python 2.5 - see the release notes (available from
the 2.5 webpage) for the full details.

There has been one very small new feature added - the
sys._current_frames() function was added. This is extremely
useful for tracking down deadlocks and related problems - 
a similar technique is already used in the popular 
DeadlockDebugger extension for Zope. It is not possible to 
do this sort of debugging from outside the Python core safely 
and robustly, which is why we've snuck this in after the 
feature freeze.

As of this release, Python 2.5 is now in *feature freeze*.
Unless absolutely necessary, no functionality changes will
be made between now and the final release of Python 2.5.

The plan is for this to be the final beta release. We should
now move to one or more release candidates, leading to
a 2.5 final release early August. PEP 356 includes the
schedule and will be updated as the schedule evolves. At
this point, any testing you can do would be greatly, greatly
appreciated.

The new features in Python 2.5 are described in Andrew
Kuchling's What's New In Python 2.5. It's available from
the 2.5 web page.

Amongst the language features added include conditional
expressions, the with statement, the merge of try/except
and try/finally into try/except/finally, enhancements to
generators to produce a coroutine kind of functionality, and
a brand new AST-based compiler implementation.

New modules added include hashlib, ElementTree, sqlite3,
wsgiref and ctypes. In addition, a new profiling module
"cProfile" was added.

Enjoy this new release,
Anthony

Anthony Baxter
[EMAIL PROTECTED]
Python Release Manager
(on behalf of the entire python-dev team)


pgplW1DKoGpz0.pgp
Description: PGP signature
___
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] [slighly OT] Native speakers and hurting brains

[Boris Borcic]

Fredrik Lundh wrote:
 > Boris Borcic wrote:
 >
 >>> in what language [is] the word "sum" an appropriate synonym for 
 >>> "concatenate" ?

 >> any that admits a+b to mean ''.join([a,b]), I'd say.
 >
 > and what human language would that be ?

Let's admit the answer is 'none' (and I apologize for accusing only English),
what is the impact on the idea that natural language intuition is a first rank
suspect, to explain the double standard in the Python treatment of str1+str2 and
sum([str1,str2]) ?

As for 'concatenate'. To my linguistic intuition it is an ugly elitist jargon
word made up for the function, like "we mean to say 'to chain' but don't want to
say it to your ears, unless you had latin classes". Admitting such a word as the
legal standard eliminates the possibility of synonyms. Makes me think, maybe
*that* word is the root of the problem, for being too ugly to find its way into
Python in the first place.

Cheers, BB

___
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] Explicit Lexical Scoping (pre-PEP?)

[Boris Borcic]

Fredrik Lundh wrote:
> Just van Rossum wrote:
> 
>> Why couldn't at least augmented assignment be implicitly rebinding? It
>> has been suggested before (in the context of a rebinding operator), but
>> I'm wondering, is this also off the table?
>>
>> def counter(num):
>> def inc():
>> num += 1
>> return num
>> return inc
>>
>> Reads very natural to me. It's likely the most frequent example of what
>> people try before they learn that rebinding to outer scopes isn't
>> allowed. It could Just Work.
> 
> note that most examples of this type already work, if the target type is 
> mutable, and implement the right operations:
> 
>   def counter(num):
>   num = mutable_int(num)
>   def inc():
>   num += 1
>   return num
>   return inc

I agree with you (and argued it in "scopes vs augmented assignment vs sets" 
recently) that mutating would be sufficient /if/ the compiler would view 
augmented assignment as mutations operators : which it doesn't as far as 
concerns scopes where a variable appears as target only of /augmented/ 
assignments.

Currently, the code you propose above will not work, and whatever your 
mutable_int() it will result in

UnboundLocalError: local variable 'num' referenced before assignment

What probably trips you is that the compiler thus makes a choice of 
interpretation that has no use cases.


Cheers, BB

___
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] [slighly OT] Native speakers and hurting brains

[Guido van Rossum]

Please end this thread. Now. Really.

-- 
--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] TRUNK is UNFROZEN.

[Anthony Baxter]

beta2 is done, so trunk is unfrozen. Remember, we're still in feature 
freeze, so new features need approval before being committed. 

Thanks!
Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Minor: Unix icons for 2.5?

[Anthony Baxter]

There's an open PEP-356 issue for "update the icons to the newer 
shinier ones" for Unix. As far as I can see, there's the 14x15 GIF 
images used for Idle and the documentation. Note that for me at least, 
idle comes up without an icon _anyway_. 

Are there any others I missed?

Anthony
-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Minor: Unix icons for 2.5?

[Georg Brandl]

Anthony Baxter wrote:
> There's an open PEP-356 issue for "update the icons to the newer 
> shinier ones" for Unix. As far as I can see, there's the 14x15 GIF 
> images used for Idle and the documentation. Note that for me at least, 
> idle comes up without an icon _anyway_. 
> 
> Are there any others I missed?

In case we add a Python .desktop file (as proposed in patch #1353344),
we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
is attached.

Georg


Index: Misc/python.desktop.in
===
--- Misc/python.desktop.in  (Revision 0)
+++ Misc/python.desktop.in  (Revision 0)
@@ -0,0 +1,14 @@
+[Desktop Entry]
+Encoding=UTF-8
+Name=Python Programming Language
+Name[sv]=Programspråket Python
+Name[de]=Die Programmiersprache Python
+Comment=Program in Python
+Comment[sv]=Programmera med Python
+Comment[de]=Programmieren in Python
+Exec=python_VER_ %f
+Terminal=true
+Type=Application
+Icon=pycon.png
+Categories=Application;Development;ConsoleOnly
+MimeType=text/x-python;application/x-python
Index: Makefile.pre.in
===
--- Makefile.pre.in (Revision 47289)
+++ Makefile.pre.in (Arbeitskopie)
@@ -89,6 +89,8 @@
 INCLUDEDIR=@includedir@
 CONFINCLUDEDIR=$(exec_prefix)/include
 SCRIPTDIR= $(prefix)/lib
+DESKTOPDIR= $(prefix)/share/applications
+ICONDIR=$(prefix)/share/icons

 # Detailed destination directories
 BINLIBDEST=$(LIBDIR)/python$(VERSION)
@@ -614,7 +616,7 @@
$(TESTPYTHON) $(TESTPROG) $(MEMTESTOPTS)

 # Install everything
-install:   @FRAMEWORKINSTALLFIRST@ altinstall bininstall maninstall
@FRAMEWORKINSTALLLAST@
+install:   @FRAMEWORKINSTALLFIRST@ altinstall bininstall maninstall
desktopinstall @FRAMEWORKINSTALLLAST@

 # Install almost everything without disturbing previous versions
 altinstall:@FRAMEWORKALTINSTALLFIRST@ altbininstall libinstall inclinstall
libainstall \
@@ -687,6 +689,25 @@
$(INSTALL_DATA) $(srcdir)/Misc/python.man \
$(DESTDIR)$(MANDIR)/man1/python.1

+# Install the .desktop file and the icons
+desktopinstall:
+   @for i in $(DESKTOPDIR) $(ICONDIR) $(ICONDIR)/hicolor
$(ICONDIR)/hicolor/16x16 $(ICONDIR)/hicolor/32x32 $(ICONDIR)/hicolor/48x48; \
+   do \
+   if test ! -d $(DESTDIR)$$i; then \
+   echo "Creating directory $$i"; \
+   $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
+   elsetrue; \
+   fi; \
+   done
+   sed 's/_VER_/$(VERSION)$(EXE)/' $(srcdir)/Misc/python.desktop.in >
$(srcdir)/Misc/python.desktop
+   $(INSTALL_DATA) $(srcdir)/Misc/python.desktop
$(DESTDIR)$(DESKTOPDIR)/python.desktop
+   for i in 16x16 32x32 48x48; \
+   do \
+   $(INSTALL_DATA) $(srcdir)/Misc/py-$$i.png
$(DESTDIR)$(ICONDIR)/hicolor/$$i/py.png; \
+   $(INSTALL_DATA) $(srcdir)/Misc/pyc-$$i.png
$(DESTDIR)$(ICONDIR)/hicolor/$$i/pyc.png; \
+   $(INSTALL_DATA) $(srcdir)/Misc/pycon-$$i.png
$(DESTDIR)$(ICONDIR)/hicolor/$$i/pycon.png; \
+   done
+
 # Install the library
 PLATDIR=   plat-$(MACHDEP)
 EXTRAPLATDIR= @EXTRAPLATDIR@
@@ -1076,7 +1097,7 @@
 # Declare targets that aren't real files
 .PHONY: all sharedmods oldsharedmods test quicktest memtest
 .PHONY: install altinstall oldsharedinstall bininstall altbininstall
-.PHONY: maninstall libinstall inclinstall libainstall sharedinstall
+.PHONY: maninstall libinstall inclinstall libainstall sharedinstall 
desktopinstall
 .PHONY: frameworkinstall frameworkinstallframework frameworkinstallstructure
 .PHONY: frameworkinstallmaclib frameworkinstallapps frameworkinstallunixtools
 .PHONY: frameworkaltinstallunixtools recheck autoconf clean clobber distclean

___
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] Capabilities / Restricted Execution

[Scott Dial]

Phillip J. Eby wrote:
> A function's func_closure contains cell objects that hold the 
> variables.  These are readable if you can set the func_closure of some 
> function of your own.  If the overall plan includes the ability to restrict 
> func_closure setting (or reading) in a restricted interpreter, then you 
> might be okay.

Except this function (__getattribute__) has been trapped inside of a
class which does not expose it as an attribute. So, you shouldn't be
able to get to the func_closure attribute of the __getattribute__
function for an instance of the Guard class. I can't come up with a way
to defeat this protection, at least. If you have a way, then I'd be
interested to hear it.

-- 
Scott Dial
[EMAIL PROTECTED]
[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] get for lists and tuples?

[Russell E. Owen]

I'd like to have the get method available for lists and tuples. (I 
figured this must have been discussed before but can't recall it and 
didn't turn anything up on google).

It's obviously not a use-all-the-time method (or it'd already be there), 
but I find myself wanting it often enough to justify it in my own mind 
(and curse this omission, relative to dict).

Basically I run into it when parsing data of variable length (where the 
extra elements have some obvious default value), including config files, 
sys.argv (for simple command scripts), that sort of thing.

Yes a 4-liner does the job, but "get" would be a much clearer way to 
write it.

Anyway, I'm just testing the waters. If it's not heresy then I'd like to 
do what I can to make it happen.

-- Russell

___
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] Minor: Unix icons for 2.5?

[Fred L. Drake, Jr.]

Anthony Baxter wrote:
 > There's an open PEP-356 issue for "update the icons to the newer
 > shinier ones" for Unix. As far as I can see, there's the 14x15 GIF
 > images used for Idle and the documentation. Note that for me at least,
 > idle comes up without an icon _anyway_.

A pyfav.(gif|png) replacement would be quite welcome!

On Tuesday 11 July 2006 13:25, Georg Brandl wrote:
 > In case we add a Python .desktop file (as proposed in patch #1353344),
 > we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
 > is attached.

I know the .desktop files have become fairly standard, but are these our 
responsibility or does that rest with the distributions/integrators?  (I'm 
not objecting, but I'm not sure what the right thing really is since Python 
is an interpreter, not a desktop application.)


  -Fred

-- 
Fred L. Drake, Jr.   
___
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] Doctest and Footnotes

[Alexander Belopolsky]

Benji York  zope.com> writes:


> 
> Here's the idea: when a footnote is referenced in prose, execute the 
> code associated with the footnote at that point.  For example:
>

Another natural place for the referenced code is the __test__ dictionary.
Using that has an advantage of not clobbering the display in the default
pydoc viewer.

___
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] get for lists and tuples?

[Georg Brandl]

Russell E. Owen wrote:
> I'd like to have the get method available for lists and tuples. (I 
> figured this must have been discussed before but can't recall it and 
> didn't turn anything up on google).
> 
> It's obviously not a use-all-the-time method (or it'd already be there), 
> but I find myself wanting it often enough to justify it in my own mind 
> (and curse this omission, relative to dict).
> 
> Basically I run into it when parsing data of variable length (where the 
> extra elements have some obvious default value), including config files, 
> sys.argv (for simple command scripts), that sort of thing.
> 
> Yes a 4-liner does the job, but "get" would be a much clearer way to 
> write it.

A 4-liner?

x = (list[i:i+1] or (default,))[0]

is just one line ;) Honestly, often enough you can work around with slices
in one or the other way.

> Anyway, I'm just testing the waters. If it's not heresy then I'd like to 
> do what I can to make it happen.

IMO there's almost no chance this can go into 2.5.

Georg

___
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] Minor: Unix icons for 2.5?

[Georg Brandl]

Fred L. Drake, Jr. wrote:
> Anthony Baxter wrote:
>  > There's an open PEP-356 issue for "update the icons to the newer
>  > shinier ones" for Unix. As far as I can see, there's the 14x15 GIF
>  > images used for Idle and the documentation. Note that for me at least,
>  > idle comes up without an icon _anyway_.
> 
> A pyfav.(gif|png) replacement would be quite welcome!
> 
> On Tuesday 11 July 2006 13:25, Georg Brandl wrote:
>  > In case we add a Python .desktop file (as proposed in patch #1353344),
>  > we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
>  > is attached.
> 
> I know the .desktop files have become fairly standard, but are these our 
> responsibility or does that rest with the distributions/integrators?  (I'm 
> not objecting, but I'm not sure what the right thing really is since Python 
> is an interpreter, not a desktop application.)

I'm also not very sure, as I myself would never start python via a menu entry.
But for newcomers, it could be as it is for Windows users: A menu entry that
starts the interpreter in a terminal window, and maybe one for IDLE too.

Georg

___
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] get for lists and tuples?

[Anthony Baxter]

On Wednesday 12 July 2006 03:39, Georg Brandl wrote:
> > Anyway, I'm just testing the waters. If it's not heresy then I'd
> > like to do what I can to make it happen.
>
> IMO there's almost no chance this can go into 2.5.

"almost"?

I'll go you one better. No way at all will it be in 2.5. And I'd be a 
firm -1 on adding in to 2.6 as well. It encourages bad coding. You 
shouldn't be searching lists and tuples like that unless you know 
what you're doing.

Anthony

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] Doctest and Footnotes

[Benji York]

Alexander Belopolsky wrote:
> Benji York  zope.com> writes:
>>Here's the idea: when a footnote is referenced in prose, execute the 
>>code associated with the footnote at that point.  For example:
>>
> 
> Another natural place for the referenced code is the __test__ dictionary.
> Using that has an advantage of not clobbering the display in the default
> pydoc viewer.

I'm not quite sure what you're suggesting.  A guess: put the code that 
isn't to be seen in the __test__ dict with a string key being the name 
of the footnote?  I don't think a ReST processor would like that much. 
It would see references to footnotes that are never defined.  Or perhaps 
you're suggesting a non-ReST mechanism for the references?

Also, for many of the use-cases we have, we do want the code in the 
test, just not in such a prominent place, and not repeated more than once.
-- 
Benji York
Senior Software Engineer
Zope Corporation
___
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] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Brett Cannon]

On 7/10/06, Talin <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Using a factory method callback, one could store the PyCodeObject in a C> proxy object that just acts as a complete delegate, forwarding all method> calls to the internally stored PyCodeObject.  That would work.
>>> For this initial implementation, though, I am not going to try to support> this.   We can always add support like this later since it doesn't> fundamentally break or change anything that is already planned.  Let's
> focus> on getting even more basic stuff working before we start to get too fancy.>> -BrettThinking about this some more, I've come up with a simpler idea for ageneric wrapper class. The wrapper consists of two parts: a decorator to
indicate that a given method is 'public', and a C 'guard' wrapper thatinsures that only 'public' members can be accessed.So for example:from Sandbox import guard, publicclass FileProxy:
   # Public method, no decoratorIs that supposed to say "no decorator", even though there is one? 
   @public   def read( length ):  ...   @public   def seek( offset ):  ...   # Private method, no decorator   def open( path ):  ...
# Construct an instance of FileProxy, and wrap a# guard object around it. Any attempt to access a non-public# attribute will raise an exception (or perhaps simply report# that the attribute doesn't exist.)
fh = guard( FileProxy() )But wouldn't you still need to protect things like object.__metaclasses__() so that you can't get access to the class and mutate it?  And if you use a custom metaclass to avoid having object expose the reference you then would need to protect the metaclass.
I guess I would need to see an implementation to see if there is any way to get around security protections since it is still Python code.
Now, from my point of view this *is* 'the basic stuff'. In other words,this right here is the fundamental sandbox mechanism, and everythingelse is built on top of it.Now, the C 'guard' function is only a low-level means to insure that
no-one can mess with the object; It is not intended to be the actualrestriction policy itself. Those are placed in the wrapper classes, justas in your proposed scheme.(This goes back to my basic premise, that a simple "yes/no" security
feature can be used to build up much more complex and subtle securityfeatures.)Yeah, this tends to be true.-Brett
The only real complexity of this, as I see it, is that methods toreferences will have to be themselves wrapped.In other words, if I say 'fh.read' without the (), what I get back can'tbe the actual read function object - that would be too easy to fiddle
with. What I'd have to get is a wrapped version of the method that is acallable.One relatively simply way to deal with this is to have the 'public'decorator create a C wrapper for the function object, and store it as an
attribute of the function. The class wrapper then simply looks up theattribute, and if it has an attribute wrapper, returns that, otherwiseit fails.(Although, I've often wished for Python to have a variant of __call__
that could be used to override individual methods, i.e.: __call_method__( self, methodname, *args )This would make the guard wrapper much easier to construct, since wecould restrict the methods only to being called, and not allow
references to methods to be taken.)-- Talin___Python-Dev mailing listPython-Dev@python.org
http://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.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] Capabilities / Restricted Execution

[Phillip J. Eby]

At 01:30 PM 7/11/2006 -0400, Scott Dial wrote:
>Phillip J. Eby wrote:
> > A function's func_closure contains cell objects that hold the
> > variables.  These are readable if you can set the func_closure of some
> > function of your own.  If the overall plan includes the ability to 
> restrict
> > func_closure setting (or reading) in a restricted interpreter, then you
> > might be okay.
>
>Except this function (__getattribute__) has been trapped inside of a
>class which does not expose it as an attribute. So, you shouldn't be
>able to get to the func_closure attribute of the __getattribute__
>function for an instance of the Guard class.

That doesn't matter, because it's the *returned* function's func_closure 
that's at issue.  That is, proxy_attr.func_closure[0] is the cell for the 
'attr' value.

___
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] Capabilities / Restricted Execution

[Talin]

Scott Dial wrote:
> Phillip J. Eby wrote:
> 
>>A function's func_closure contains cell objects that hold the 
>>variables.  These are readable if you can set the func_closure of some 
>>function of your own.  If the overall plan includes the ability to restrict 
>>func_closure setting (or reading) in a restricted interpreter, then you 
>>might be okay.
> 
> 
> Except this function (__getattribute__) has been trapped inside of a
> class which does not expose it as an attribute. So, you shouldn't be
> able to get to the func_closure attribute of the __getattribute__
> function for an instance of the Guard class. I can't come up with a way
> to defeat this protection, at least. If you have a way, then I'd be
> interested to hear it.

I've thought of several ways to break it already. Some are repairable, 
I'm not sure that they all are.

For example, neither of the following statements blows up:

print t2.get_name.func_closure[0]
print object.__getattribute__( t2, '__dict__' )

Still, its perhaps a useful basis for experimentation.

-- Talin
___
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] Doctest and Footnotes

[Alexander Belopolsky]

On 7/11/06, Benji York <[EMAIL PROTECTED]> wrote:
[snip]
> I'm not quite sure what you're suggesting.  A guess: put the code that
> isn't to be seen in the __test__ dict with a string key being the name
> of the footnote?

That's right.

>  I don't think a ReST processor would like that much.
> It would see references to footnotes that are never defined.  Or perhaps
> you're suggesting a non-ReST mechanism for the references?
>

I don't know how ReST processor is used.  If you just filter the
output of pydoc through a ReST processor, then you are right about
undefined references. If, however, ReST processing is implemented
inside pydoc, I don't see any problem in implementing __test__ lookup.

> Also, for many of the use-cases we have, we do want the code in the
> test, just not in such a prominent place, and not repeated more than once.

I my use-cases, testing code is clobbering the documentation, but
there is no easy way to move it outside of the docstrings without
breaking the order of evaluation.  I don't use a ReST processor, by I
can read ReST formatted text with little difficulty. I would greatly
appreciate if I could clean the docstrings without loosing the tests.

BTW, another feature that I would greatly appreciate would be a
unittest wrapper which makes each docstring in a separate test case.
Also __new__ and __init__ method docstrings is the natural place to
put set-up code.
___
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] Doctest and Footnotes

[Fred Drake]

On Tuesday 11 July 2006 14:12, Alexander Belopolsky wrote:
 > Also __new__ and __init__ method docstrings is the natural place to
 > put set-up code.

Maybe, if all the tests required the same setup code.  That's often not the 
case.


  -Fred

-- 
Fred L. Drake, Jr.  
Zope Corporation
___
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] get for lists and tuples?

[Georg Brandl]

Anthony Baxter wrote:
> On Wednesday 12 July 2006 03:39, Georg Brandl wrote:
>> > Anyway, I'm just testing the waters. If it's not heresy then I'd
>> > like to do what I can to make it happen.
>>
>> IMO there's almost no chance this can go into 2.5.
> 
> "almost"?
> 
> I'll go you one better. No way at all will it be in 2.5. And I'd be a 
> firm -1 on adding in to 2.6 as well. It encourages bad coding. You 
> shouldn't be searching lists and tuples like that unless you know 
> what you're doing.

NB: I did not support adding that method, only notified the OP of the
2.5 situation.

Georg

___
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] get for lists and tuples?

[Raymond Hettinger]

Russell E. Owen wrote:

>I'd like to have the get method available for lists and tuples. (I 
>figured this must have been discussed before but can't recall it and 
>didn't turn anything up on google).
>
>It's obviously not a use-all-the-time method (or it'd already be there), 
>but I find myself wanting it often enough to justify it in my own mind 
>(and curse this omission, relative to dict).
>
>Basically I run into it when parsing data of variable length (where the 
>extra elements have some obvious default value), including config files, 
>sys.argv (for simple command scripts), that sort of thing.
>  
>
How about:

optarg = argv[4] if len(argv)>4 else 'default'


>Yes a 4-liner does the job, but "get" would be a much clearer way to 
>write it.
>
>Anyway, I'm just testing the waters. If it's not heresy then I'd like to 
>do what I can to make it happen.
>  
>

Perhaps in an alternate universe ;-)


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] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Phillip J. Eby]

At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:
>On 7/10/06, Talin <[EMAIL PROTECTED]> wrote:
>>(Although, I've often wished for Python to have a variant of __call__
>>that could be used to override individual methods, i.e.:
>>
>>  __call_method__( self, methodname, *args )

As with so many other things in this discussion, this was already invented 
by the Zope folks just shy of a decade ago.  ;-)  __call_method__ is 
actually a feature of ExtensionClasses, although you can of course 
implement it yourself now atop new-style classes.

For other things that Zope has already done in the area of restricted 
execution R&D, see:

http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?view=auto

The surrounding directory has other documents regarding their approach.

I haven't been following this discussion closely, but a lot of the things 
mentioned in this thread seem to have a lot in common with stuff the Zope 
folks have had in production for "untrusted" Python execution for some time 
now, working with current versions of Python.  It would be a shame to 
reinvent all the same wheels, especially since their code is nicely 
documented complete with extensive doctests and explanations of the approach.

___
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] Doctest and Footnotes

[Phillip J. Eby]

At 02:12 PM 7/11/2006 -0400, Alexander Belopolsky wrote:
>On 7/11/06, Benji York <[EMAIL PROTECTED]> wrote:
>[snip]
> > I'm not quite sure what you're suggesting.  A guess: put the code that
> > isn't to be seen in the __test__ dict with a string key being the name
> > of the footnote?
>
>That's right.
>
> >  I don't think a ReST processor would like that much.
> > It would see references to footnotes that are never defined.  Or perhaps
> > you're suggesting a non-ReST mechanism for the references?
> >
>
>I don't know how ReST processor is used.  If you just filter the
>output of pydoc through a ReST processor, then you are right about
>undefined references.

A common use case for doctests in Zope is separate text files that are used 
as documentation.  I also use this approach for generating documentation 
myself, e.g.:

http://chandler.osafoundation.org/docs/0.7/parcel-schema-guide.html
http://chandler.osafoundation.org/docs/0.7/running-code-at-startup.html
http://peak.telecommunity.com/DevCenter/BytecodeAssembler

To name just a few.

___
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] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Brett Cannon]

On 7/11/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:>On 7/10/06, Talin <[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:>>(Although, I've often wished for Python to have a variant of __call__
>>that could be used to override individual methods, i.e.:  __call_method__( self, methodname, *args )As with so many other things in this discussion, this was already invented
by the Zope folks just shy of a decade ago.  ;-)  __call_method__ isactually a feature of ExtensionClasses, although you can of courseimplement it yourself now atop new-style classes.For other things that Zope has already done in the area of restricted
execution R&D, see:http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?view=auto
The surrounding directory has other documents regarding their approach.I haven't been following this discussion closely, but a lot of the thingsmentioned in this thread seem to have a lot in common with stuff the Zope
folks have had in production for "untrusted" Python execution for some timenow, working with current versions of Python.  It would be a shame toreinvent all the same wheels, especially since their code is nicely
documented complete with extensive doctests and explanations of the approach.Taking a proxy approach is just being discussed; it has not been decided as the proper solution.  I have been considering just preventing direct 'file' access and using open() to act as a delegate for opening files.  That approach has nothing to do with proxies.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doctest and Footnotes

[Alexander Belopolsky]

On 7/11/06, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Tuesday 11 July 2006 14:12, Alexander Belopolsky wrote:
>  > Also __new__ and __init__ method docstrings is the natural place to
>  > put set-up code.
>
> Maybe, if all the tests required the same setup code.  That's often not the
> case.

That's true, but you cannot test an object method without creating the
object first.  For the main cases you would want the object definition
close to the test for the benefit of people who do pydoc Foo.bar, but
for corner cases it is better to have a predefined set of exotic
objects available under descriptive names.  I am also advocating
__init__ docstring because in my use-cases it rarely much of
documentation because object construction is documented in the class
docstring, therefore test set-up code placed in __init__ docstring is
unlikely to clobber often-used documentation.
___
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] urllib.quote and unicode bug resuscitation attempt

[John J Lee]

On Tue, 11 Jul 2006, Stefan Rank wrote:

> urllib.quote fails on unicode strings and in an unhelpful way::
[...]
>   >>> urllib.quote(u'a\xf1a')
>   Traceback (most recent call last):
> File "", line 1, in ?
> File "C:\Python24\lib\urllib.py", line 1117, in quote
>   res = map(safe_map.__getitem__, s)
>   KeyError: u'\xf1'

More helpful than silently producing the wrong answer.


[...]
> I suggest to add (after 2.5 I assume) one of the following to the
> beginning of urllib.quote to either fail early and consistently on
> unicode arguments and improve the error message::
>
>   if isinstance(s, unicode):
>   raise TypeError("quote needs a byte string argument, not unicode,"
>   " use `argument.encode('utf-8')` first.")

Won't this break existing code that catches the KeyError, for no big 
benefit?  If nobody is yet sure what the Right Thing is (see below), I 
think we should not change this yet.


> or to do The Right Thing (tm), which is utf-8 encoding::
>
>   if isinstance(s, unicode):
>   s = s.encode('utf-8')
>
> as suggested in
> http://www.w3.org/International/O-URL-code.html
> and rfc3986.

You seem quite confident of that.  You may be correct, but have you read 
all of the following?  (not trying to claim superior knowledge by asking 
that, I just dunno what the right thing is yet: I haven't yet read RFC 
2617 or got my head around what the unicode issues are or how they should 
apply to the Python stdlib)

http://www.ietf.org/rfc/rfc2617.txt

http://www.ietf.org/rfc/rfc2616.txt

http://en.wikipedia.org/wiki/Percent-encoding

http://mail.python.org/pipermail/python-dev/2004-September/048944.html


Also note the recent discussions here about a module named "uriparse" or 
"urischemes", which fits in to this somewhere.  It would be good to make 
all the following changes in a single Python release (2.6, with luck):

  - extend / modify urllib and urllib2 to handle unicode input

  - address the urllib.quote issue you raise above (+ consider the other
utility functions in that module)

  - add the urischemes module


In summary, I agree that your suggested fix (and all of the rest I refer 
to above) should wait for 2.6, unless somebody (Martin?) who understands 
all these issues is quite confident your suggested change is OK. 
Presumably the release managers wouldn't allow it in 2.5 anyway.


John
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Doctest and Footnotes

[Fred Drake]

On Tuesday 11 July 2006 14:37, Alexander Belopolsky wrote:
 > That's true, but you cannot test an object method without creating the
 > object first.  

True.  How the object is created can vary; if the creation affects the 
expected behavior in any way, you'll need be careful about how the 
constructor is called for that test.  In fact, __init__ isn't always the 
desired constructor; some other class method might be used.

 > For the main cases you would want the object definition 
 > close to the test for the benefit of people who do pydoc Foo.bar, but
 > for corner cases it is better to have a predefined set of exotic
 > objects available under descriptive names.  

This is subjective.  That's certainly one way of organizing the tests, and 
I've no problem with it, but some of us use a more narrative approach, and we 
don't want our test structure to be constrained by the layout of the source 
code.

Gary's idea about using footnotes to aid in structuring tests is only about 
enabling a particular approach to structure, not about requiring it.  If it 
doesn't fit your needs, there's certainly no need to use it.  For more 
elaborate test structures, I suspect it will prove quite useful.  I also 
expect it will be more helpful for tests in separate text files than for 
tests embedded in source code.


  -Fred

-- 
Fred L. Drake, Jr.  
Zope Corporation
___
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] In defense of Capabilities [was: doc for new restricted execution design for Python]

[Phillip J. Eby]

At 11:35 AM 7/11/2006 -0700, Brett Cannon wrote:
>On 7/11/06, Phillip J. Eby 
><[EMAIL PROTECTED]> wrote:
>>At 10:56 AM 7/11/2006 -0700, Brett Cannon wrote:
>> >On 7/10/06, Talin 
>> <[EMAIL PROTECTED]> 
>> wrote:
>> >>(Although, I've often wished for Python to have a variant of __call__
>> >>that could be used to override individual methods, i.e.:
>> >>
>> >>  __call_method__( self, methodname, *args )
>>
>>As with so many other things in this discussion, this was already invented
>>by the Zope folks just shy of a decade ago.  ;-)  __call_method__ is
>>actually a feature of ExtensionClasses, although you can of course
>>implement it yourself now atop new-style classes.
>>
>>For other things that Zope has already done in the area of restricted
>>execution R&D, see:
>>
>>http://svn.zope.org/Zope3/trunk/src/zope/security/untrustedinterpreter.txt?view=auto
>>
>>The surrounding directory has other documents regarding their approach.
>>
>>I haven't been following this discussion closely, but a lot of the things
>>mentioned in this thread seem to have a lot in common with stuff the Zope
>>folks have had in production for "untrusted" Python execution for some time
>>now, working with current versions of Python.  It would be a shame to
>>reinvent all the same wheels, especially since their code is nicely
>>documented complete with extensive doctests and explanations of the approach.
>
>Taking a proxy approach is just being discussed; it has not been decided 
>as the proper solution.

My point is more to the study of the requirements for untrusted execution, 
and what options are open within the existing CPython architecture.  Many 
aspects of the Zope untrusted interpreter do *not* involve proxies; there 
are quite a few simple types that Zope's untrusted interpreter allows 
direct access to.  See the section on "Basic objects" in the link above.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 356: python.org/sf/1515343 resolution

[Jim Jewett]

python.org/sf/1515343 fixes a regression against 2.4, which masks
exceptions, and should therefore go in before release.  The tracker
has a patch to the test cases, and two alternative fixes.  (One
minimal, the other less ugly.)

Since this only affects string exceptions with a value, it might be
acceptable to just say "won't ever fix", but then it should be added
to the upgrade news.

-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] urllib.quote and unicode bug resuscitation attempt

[Martin v. Löwis]

Stefan Rank wrote:
> I suggest to add (after 2.5 I assume) one of the following to the 
> beginning of urllib.quote to either fail early and consistently on 
> unicode arguments and improve the error message::
> 
>if isinstance(s, unicode):
>raise TypeError("quote needs a byte string argument, not unicode,"
>" use `argument.encode('utf-8')` first.")
> 
> or to do The Right Thing (tm), which is utf-8 encoding::

The right thing to do is IRIs. This is more complicated than encoding
the Unicode string as UTF-8, though: for the host part of the URL, you
have to encode it with IDNA (and there are additional complicated rules
in place, e.g. when the Unicode string already contains %).

Contributions are welcome, as long as they fix this entire issue "for
good" (i.e. in all URL-processing code, and considering all relevant
RFCs).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

[Terry Reedy]

"Boris Borcic" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> I agree with you (and argued it in "scopes vs augmented assignment vs 
> sets"
> recently) that mutating would be sufficient /if/ the compiler would view
> augmented assignment as mutations operators :

Mutation is an operation on objects.  Binding is an operation on 
namespaces.  The difference between objects and namespaces (and the actions 
thereupon) is fundamental to Python.  Asking the interpreter to view one 
thing as something else which it isn't can only lead to more confusion.  In 
particular, asking that arithmetic operations on immutable numbers be seen 
as mutations seems wacky to me.

> which it doesn't as far as  concerns scopes where a variable
> appears as target only of /augmented/ assignments.

The interpreter/compiler, as far as I can think, never views binding as 
mutation, nor should it.  The request that it do so makes me wonder whether 
it might have been a mistake to allow mutable objects in an augmented 
assignment to choose to implement the associated operation as an in-place 
mutation.

Terry Jan 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] Minor: Unix icons for 2.5?

[Martin v. Löwis]

Georg Brandl wrote:
> In case we add a Python .desktop file (as proposed in patch #1353344),
> we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
> is attached.

Independent of whether this should be done at all, I have a comment on
the patch. Instead of invoking sed, I would use autoconf machinery here

> +Exec=python_VER_ %f

This would become

[EMAIL PROTECTED]@@EXEEXT@ %f

> +   sed 's/_VER_/$(VERSION)$(EXE)/' $(srcdir)/Misc/python.desktop.in >
> $(srcdir)/Misc/python.desktop

This could go away, and configure should grow

AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.desktop)



Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor: Unix icons for 2.5?

[BJörn Lindqvist]

> I know the .desktop files have become fairly standard, but are these our
> responsibility or does that rest with the distributions/integrators?  (I'm
> not objecting, but I'm not sure what the right thing really is since Python
> is an interpreter, not a desktop application.)

The same anal argument could of course be made for every piece of
software. Is Emacs a desktop application or a lisp interpreter? Is vim
a desktop app? Are games? There is no reason add yet another task to
to multiple distributors/integrators (that they won't do) when the
problem can be fixed at the source.

-- 
mvh Björn
___
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] Minor: Unix icons for 2.5?

[Georg Brandl]

Martin v. Löwis wrote:
> Georg Brandl wrote:
>> In case we add a Python .desktop file (as proposed in patch #1353344),
>> we'll need some PNGs in /usr/share/icons. A patch for Makefile.pre.in
>> is attached.
> 
> Independent of whether this should be done at all, I have a comment on
> the patch. Instead of invoking sed, I would use autoconf machinery here
> 
>> +Exec=python_VER_ %f
> 
> This would become
> 
> [EMAIL PROTECTED]@@EXEEXT@ %f
> 
>> +   sed 's/_VER_/$(VERSION)$(EXE)/' $(srcdir)/Misc/python.desktop.in >
>> $(srcdir)/Misc/python.desktop
> 
> This could go away, and configure should grow
> 
> AC_CONFIG_FILES(Makefile.pre Modules/Setup.config Misc/python.desktop)

Ah, thanks. I'm not very fit with autoconf magic.

Georg

___
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] User's complaints

[Michael Ellerman]

On 7/5/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 7/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> >  From actual users of
> > the language I get more complaints about the breakneck speed of
> > Python's evolution than about the brokenness of the current language.
>
> Guido,
>
> I'm really interested in your perspective here.  I assume you hear far
> more "average" complaints from Joe Random User.  Can you help give the
> rest of us an idea about the top 10 complaints/problems people have?
> I realize this will be subjective, that's ok.  Perhaps we should try
> to focus our energies on some of these issues.

Well here's one I stumbled across the other day. I don't know if it's
legit, but it's still bad PR:

http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html

For the impatient, he's not at all bothered about the lack of obscure
language feature X.

cheers
___
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] Autoloading? (Making Queue.Queue easier to use)

[Perkins, Christopher]

John,

I see what you are doing with the algorithm now, and I can easily re-factor
it.  What I am having issues with is how structured it is.  5 minute
windows?  Then running hours will always be recorded in 1/12th time steps.

Would it not be more accurate to record engine time where the breaker was
closed?

-chris
___
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] User's complaints

[skip]

Michael> Well here's one I stumbled across the other day. I don't know
Michael> if it's legit, but it's still bad PR:

Michael> http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html

Michael> For the impatient, he's not at all bothered about the lack of
Michael> obscure language feature X.

The way I used to format dates using time.strftime does indeed no longer
work.

Python 2.3:

>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
'2005-06-04'

Python 2.4 or 2.5:

>>> import time
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
Traceback (most recent call last):
  File "", line 1, in ?
ValueError: day of year out of range
>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (1,)*6)
'2005-06-04'

I don't actually run into this problem as I've pretty much converted to use
datetime in new code.  I also realize that's not documented as the way it
should be done, but I'm fairly certain it was common usage before the
datetime module came along.  Still, it is a bit annoying that the
(undocumented, but I think de facto) commonly used idiom no longer works.

(In fact, it always bothered me a bit that I had to even provide the unused
values.)

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] User's complaints

[Brett Cannon]

On 7/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Michael> Well here's one I stumbled across the other day. I don't knowMichael> if it's legit, but it's still bad PR:Michael> 
http://www.gbch.net/gjb/blog/software/discuss/python-sucks.htmlMichael> For the impatient, he's not at all bothered about the lack ofMichael> obscure language feature X.
That whole entry is a little overblown.  I mean the guy has a single issue with a change and he gives up on the language after only the second one?  Try using any language that is under active development and show me stuff that won't break.  I think it shows how hard we work to not break things that this guy only got bit twice, and at least the second time was minor and had a legit reason for the change.
The way I used to format dates using time.strftime does indeed no longerwork.
Python 2.3:>>> import time>>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)'2005-06-04'Python 2.4 or 2.5:>>> import time>>> 
time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)Traceback (most recent call last):  File "", line 1, in ?ValueError: day of year out of range>>> time.strftime
("%Y-%m-%d", (2005, 6, 4) + (1,)*6)'2005-06-04'That was done to fix buffer overflow issues when libc implementations didn't do bound checks on the arguments to strftime() and would index too far (
e.g., setting the month as 20 indexes too far and setting to 0 can be an issue as well since the array indexing for the month name will be January, and thus will most likely do ``mon - 1`` to get the index into the array). 
I don't actually run into this problem as I've pretty much converted to use
datetime in new code.  I also realize that's not documented as the way itshould be done,It is the last point in the first paragraph on time.strftime() discussing what changed in Python 2.4 as to what the change was.  It's also in Misc/NEWS .  Basically the guy didn't read the release notes or the docs to see why that changed and that it was legitimate and needed for stability.
 but I'm fairly certain it was common usage before thedatetime module came along.  Still, it is a bit annoying that the
(undocumented, but I think de facto) commonly used idiom no longer works.As I said, stability called for the need to make the change.  It was discussed on python-dev when it came up.
(In fact, it always bothered me a bit that I had to even provide the unusedvalues.)
That would probably be fine to add in 2.6 .  Should be a huge issue.  You could also change the function to detect values of 0 when provided and then automatically use defaults in those cases that are within the proper range.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] User's complaints

[skip]

Brett> That whole entry is a little overblown.  

Well, sure.  Think of it as a bug report with attitude. ;-)

Brett> That was done to fix buffer overflow issues when libc
Brett> implementations didn't do bound checks on the arguments to
Brett> strftime() and would index too far...

That special case could simply be recognized and converted into one that
works couldn't it?  Documented or not, I believe it was the standard idiom
for formatting just a date before 2.4.

http://python.org/sf/1520914

Keep or toss as you see fit.  Seems like breakage that could have been
avoided to me though.

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] urllib.quote and unicode bug resuscitation attempt

[Anthony Baxter]

On Wednesday 12 July 2006 07:16, Martin v. Löwis wrote:
> Stefan Rank wrote:
> > I suggest to add (after 2.5 I assume) one of the following to the
> > beginning of urllib.quote to either fail early and consistently
> > on unicode arguments and improve the error message::
> >
> >if isinstance(s, unicode):
> >raise TypeError("quote needs a byte string argument, not
> > unicode," " use `argument.encode('utf-8')` first.")
> >
> > or to do The Right Thing (tm), which is utf-8 encoding::
>
> The right thing to do is IRIs. This is more complicated than
> encoding the Unicode string as UTF-8, though: for the host part of
> the URL, you have to encode it with IDNA (and there are additional
> complicated rules in place, e.g. when the Unicode string already
> contains %).
>
> Contributions are welcome, as long as they fix this entire issue
> "for good" (i.e. in all URL-processing code, and considering all
> relevant RFCs).

For 2.5, should we at least detect that it's unicode and raise a 
useful error?


-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
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] changing time.strftime() to accept 0s (was: User's complaints)

[Brett Cannon]

On 7/11/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Brett> That whole entry is a little overblown.Well, sure.  Think of it as a bug report with attitude. ;-)Brett> That was done to fix buffer overflow issues when libcBrett> implementations didn't do bound checks on the arguments to
Brett> strftime() and would index too far...That special case could simply be recognized and converted into one thatworks couldn't it?  Documented or not, I believe it was the standard idiomfor formatting just a date before 
2.4.http://python.org/sf/1520914Keep or toss as you see fit.  Seems like breakage that could have beenavoided to me though.Right, but that would have required realizing how to prevent it at the time.  =)
I can change it so that 0 is an acceptable value and internally handles defaulting to something reasonable (accepting less than 9 values in the tuple is a separate thing that I don't feel like bothering to implement).  It does possibly hide bugs where 0 was not meant to be passed, though.
If people think this is a reasonable thing to change, then Neal and Anthony, do you want it to go into 2.5?-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)

[Greg Ewing]

Matthew Barnes wrote:
> its
> meaning in C/C++ (i.e. the symbol is defined outside of the current
> scope).

It means more than that -- it means defined outside
the current *file*. That's much too drastic for
what we want.

--
Greg
___
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] [slighly OT] Native speakers and hurting brains

[Nick Coghlan]

Fredrik Lundh wrote:
> Boris Borcic wrote:
> 
>>> in what language [is] the word "sum" an appropriate synonym for 
>>> "concatenate" ?
>> any that admits a+b to mean ''.join([a,b]), I'd say.
> 
> and what human language would that be ?

Python :)

Sure-computers-can-speak-it-but-so-can-humans'ly yours,
Nick.


-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.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] [slighly OT] Native speakers and hurting brains

[Greg Ewing]

Boris Borcic wrote:

> sum() *is* exactly an attractive nuisance by *appearing* to be an obvious way 
> of 
> chaining strings in a list (without actually being one).

But at least it fails immediately, prompting you to
look in another direction.

> I admit that there is a step of arguable interpretation from these recorded 
> facts to my diagnostic, but the latter is compatible with the facts. Your 
> version otoh looks more robust in the role of eg creation myth.

I suppose you could call that a linguistic matter, but
I don't think it's exclusively a *native* one. I suspect
that only someone with a programmer's warped mind would
make the leap from "sum" to "string concatenation" --
whether they were a native English speaker or not.

Also I don't see that my version of events is inconsistent
with the messages you quoted either -- at least not so much
as to be relegated to a myth!

--
Greg
___
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] [slighly OT] Native speakers and hurting brains

[Greg Ewing]

Gareth McCaughan wrote:

> (I agree that Greg's interpretation is also not well supported
> by that thread;

I was perhaps a bit excessive in claiming that language
had nothing to do with it. What I meant was that it
wasn't the *only* consideration. If there hadn't been
any disadvantages, quite possibly the ability to use
sum() on strings would have been supported, or at
least not actively blocked.

But because of the disadvantage I mentioned, *together*
with the fact that it's an odd meaning for "sum" (whether
you're a native English speaker or not), the decision was
made to disallow it.

Does that version sound less like a creation myth?-)

--
Greg
___
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] [slighly OT] Native speakers and hurting brains

[Greg Ewing]

Boris Borcic wrote:
> Fredrik Lundh wrote:
> 
>>in what language the word "sum" an appropriate synonym for "concatenate" ?
> 
> any that admits a+b to mean ''.join([a,b]), I'd say.

Not the same thing. "a + b" is usually pronounced
"a plus b". Now, "plus" has a somewhat wider meaning
than "sum". It sounds quite in order to say things
like "I have a sandwich plus an apple in my lunch
box", but it would be odd to say "I have the sum
of a sandwich and an apple in my lunch box".

--
Greg
___
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] urllib.quote and unicode bug resuscitation attempt

[Martin v. Löwis]

Anthony Baxter wrote:
>> The right thing to do is IRIs. 
> 
> For 2.5, should we at least detect that it's unicode and raise a 
> useful error?

That can certainly be done, sure.

Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] changing time.strftime() to accept 0s (was: User's complaints)

[Anthony Baxter]

Making strftime accept 0s is fine to be checked in, since it's a 
regression (an understandable one, but what the hell). Making it 
accept less than 9 items and have useful defaults should wait for 2.6
___
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] changing time.strftime() to accept 0s (was: User'scomplaints)

[Terry Reedy]

"Anthony Baxter" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Making strftime accept 0s is fine to be checked in, since it's a
> regression (an understandable one, but what the hell).

Once it is, someone should  put a note back on the complainant's blog page. 



___
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] User's complaints

[Martin v. Löwis]

[EMAIL PROTECTED] wrote:
> The way I used to format dates using time.strftime does indeed no longer
> work.
> 
> Python 2.3:
> 
> >>> import time
> >>> time.strftime("%Y-%m-%d", (2005, 6, 4) + (0,)*6)
> '2005-06-04'

Is there any specific reason you couldn't write

"%d-%02d-%02d" % (2005, 6, 4)

(i.e. not use strftime at all)? It seems strange to fake a time tuple
just to use that function, in particular if the time formatting should
not use any locale-specific output.

> I don't actually run into this problem as I've pretty much converted to use
> datetime in new code.  I also realize that's not documented as the way it
> should be done, but I'm fairly certain it was common usage before the
> datetime module came along.  Still, it is a bit annoying that the
> (undocumented, but I think de facto) commonly used idiom no longer works.

I guess this was caused by this change:

/* Checks added to make sure strftime() does not crash Python by
   indexing blindly into some array for a textual representation
   by some bad index (fixes bug #897625).

   No check for year since handled in gettmarg().
*/

So this was changed in response to a bug report about a crash.


Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com