date:20080627

[Python-Dev] deepcopy

2008-06-27 Thread Walter Bender


Hello togehter,

I get an error while doing a deep copy of an "event". An event is an 
object, with has a lot of __dict__["attr"]  = Event("SAMPLE") OTHER 
Events added to the object (no self refence) and store additional 
__dict__["attr2"] =  2 informations.


deep copy is failing with no proper error message.


   nevent = copy.deepcopy(event);
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 174, in deepcopy

   y = copier(x, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 305, in _deepcopy_inst

   state = deepcopy(state, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 174, in deepcopy

   y = copier(x, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 268, in _deepcopy_dict

   y[deepcopy(key, memo)] = deepcopy(value, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 174, in deepcopy

   y = copier(x, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 241, in _deepcopy_list

   y.append(deepcopy(a, memo))
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 174, in deepcopy

   y = copier(x, memo)
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 241, in _deepcopy_list

   y.append(deepcopy(a, memo))
 File 
"/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py", 
line 185, in deepcopy

   y = copier(x, memo)
TypeError: __deepcopy__() takes no arguments (1 given

cheers,
Walter

--
Walter Bender
[EMAIL PROTECTED]
RWTH Aachen
III. Physikalisches Institut A
Tel. +49-241-8027286

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

Re: [Python-Dev] Undocumenting test.support in 3.x (was Py3k DeprecationWarning in stdlib)

2008-06-27 Thread Nick Coghlan


Benjamin Peterson wrote:

On Thu, Jun 26, 2008 at 10:34 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

On Thu, Jun 26, 2008 at 8:32 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:

I'm personally fine with that approach, but some of the new items in there
for 2.6 could probably use a bit of cleaning up to improve the APIs and/or
the way they work.

So get crackin'!


I'll add to my list. :)

Anyway, if we are going to make test.support public for real why don't
we take Nick's suggestion to rename the test package to _test, but
move test.support to a toplevel position like testutils or such.


Leaving the actual test modules undocumented (which is the situation 
now) is fine in my opinion. The _test idea was just for if we wanted to 
document test_support for our own benefit without promising to keep it 
stable for later releases.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-27 Thread Nick Coghlan


[EMAIL PROTECTED] wrote:


I do tend to ramble on, so here's an executive summary of my response:

I want python developers to pay attention to the community buildbots and 
to treat breakages of existing projects as a serious issue.


Counter-proposal:

* Interested developers or users of the major third party projects 
tested by the community buildbots should monitor the community 
buildbots, and start filing bug reports with the appropriate party as 
soon as the upcoming Python release hits 2.Xa1 (i.e. first alpha).


* If the failure is due to an incompatibility between Python 2.X and 
2.X-1, then the bug report should be filed against Python. While these 
issues may or may not be addressed before the first beta, they *must* be 
addressed before the first release candidate.


* If the failure is due to an incompatibility between Python 2.X and 
2.X-2 that was properly deprecated in 2.X-1, then the bug report should 
be filed against the third party project. Prioritising these is a 
question for the developers of that project.


* Before filing a bug report against Python for a community buildbot 
failure, check if the relevant regression is also causing failures of 
the core buildbots. If it is, skip the bug report until the core 
buildbots are passing again.


It's currently a fact of life that we do NOT keep the trunk in an 
always-releasable state. We just don't. It might be nice if we did, 
there are lots of reasons why that's a good way to run a project, but at 
this point in time it isn't the case with Python. Reacting every time a 
community buildbot goes red would be a serious waste of effort.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] deepcopy

2008-06-27 Thread Amaury Forgeot d'Arc

Walter Bender wrote:
Hello togehter,
>
> I get an error while doing a deep copy of an "event". An event is an object,
> with has a lot of __dict__["attr"]  = Event("SAMPLE") OTHER Events added to
> the object (no self refence) and store additional __dict__["attr2"] =  2
> informations.
>
> deep copy is failing with no proper error message.
>
>
>   nevent = copy.deepcopy(event);
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 174, in deepcopy
>   y = copier(x, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 305, in _deepcopy_inst
>   state = deepcopy(state, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 174, in deepcopy
>   y = copier(x, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 268, in _deepcopy_dict
>   y[deepcopy(key, memo)] = deepcopy(value, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 174, in deepcopy
>   y = copier(x, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 241, in _deepcopy_list
>   y.append(deepcopy(a, memo))
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 174, in deepcopy
>   y = copier(x, memo)
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 241, in _deepcopy_list
>   y.append(deepcopy(a, memo))
>  File
> "/net/software_cms/slc4_ia32_gcc345/external/python/2.4.2-CMS3q/lib/python2.4/copy.py",
> line 185, in deepcopy
>   y = copier(x, memo)
> TypeError: __deepcopy__() takes no arguments (1 given

It's possible that "event" contains an object that cannot be copied.
>From the traceback, one can see that your object has an attribute that
is a list of lists, and the failing object is there.
Googling for the error message suggests that the object could be an
array.array.
The corresponding problem was corrected with python 2.4.4.

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Vacation

2008-06-27 Thread Thomas Heller

FYI: I'm going to a vacation for the next two or three weeks.
I will shutdown my buildbots, and restart them when I'm back:

x86 osx.5, x86 XP-3, amd64 XP.

Sorry for the inconvenience,
Thomas

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

[Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Chris AtLee

Hello,

I notice that there is some work being done on urllib / urllib2 for
python 2.6/3.0.  One thing I've always missed in urllib/urllib2 is the
facility to encode POST data as multipart/form-data.  I think it would
also be useful to be able to stream a POST request to the remote
server rather than having requiring the user to create the entire POST
body in memory before starting the request.  This would be extremely
useful when writing any kind of code that does file uploads.

I didn't see any recent discussion about this so I thought I'd ask
here: do you think this would make a good addition to the new urllib
package?

Cheers,
Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Bill Janssen

> I notice that there is some work being done on urllib / urllib2 for
> python 2.6/3.0.  One thing I've always missed in urllib/urllib2 is the
> facility to encode POST data as multipart/form-data.  I think it would
> also be useful to be able to stream a POST request to the remote
> server rather than having requiring the user to create the entire POST
> body in memory before starting the request.  This would be extremely
> useful when writing any kind of code that does file uploads.
> 
> I didn't see any recent discussion about this so I thought I'd ask
> here: do you think this would make a good addition to the new urllib
> package?

I think it would be very helpful.  I'd separate the two things,
though; you want to be able to format a set of values as
"multipart/form-data", and do various things with that resulting
"document", and you want to be able to stream a POST (or PUT) request.

Bill
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

2008-06-27 Thread Python tracker


ACTIVITY SUMMARY (06/20/08 - 06/27/08)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 1933 open (+40) / 13106 closed (+25) / 15039 total (+65)

Open issues with patches:   600

Average duration of open issues: 707 days.
Median duration of open issues: 1532 days.

Open Issues Breakdown
   open  1908 (+39)
pending25 ( +1)

Issues Created Or Reopened (69)
___

Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.  06/25/08
   http://bugs.python.org/issue1682reopened marketdickinson   
   patch   

pickling of large recursive structures crashes cPickle   06/25/08
   http://bugs.python.org/issue2702reopened facundobatista
   patch   

Let bin/oct/hex show floats  06/25/08
   http://bugs.python.org/issue3008reopened rhettinger
   patch   

ast module docs document private attribute   06/20/08
CLOSED http://bugs.python.org/issue3152created  brett.cannon  
   easy, 26backport

sqlite leaks on error06/20/08
   http://bugs.python.org/issue3153created  Rhamphoryncus 
   

"Quick search" box renders too long on FireFox 3 06/20/08
   http://bugs.python.org/issue3154created  tebeka
   

Python should expose a pthread_cond_timedwait API for threading  06/20/08
   http://bugs.python.org/issue3155created  gregory.p.smith   
   

bytes type has inconsistent methods (append, insert) 06/20/08
   http://bugs.python.org/issue3156created  akuchling 
   patch   

sqlite3 minor documentation issues   06/21/08
CLOSED http://bugs.python.org/issue3157created  slewis
   

Doctest fails to find doctests in extension modules  06/21/08
   http://bugs.python.org/issue3158created  fer_perez 
   

glob.py improvements 06/21/08
   http://bugs.python.org/issue3159created  Indy  
   patch   

Building a Win32 binary installer crashes06/21/08
   http://bugs.python.org/issue3160created  complex   
   

Missing import for sys in _abcoll06/21/08
CLOSED http://bugs.python.org/issue3161created  hodgestar 
   patch   

ssl.SSLSocket implements methods that are overriden by socket.so 06/21/08
   http://bugs.python.org/issue3162created  hodgestar 
   

module struct support for ssize_t and size_t 06/21/08
   http://bugs.python.org/issue3163created  MrJean1   
   patch   

cPickle calls to save_string and save_unicode with unicode objec 06/21/08
CLOSED http://bugs.python.org/issue3164created  cuerty
   patch   

cPickle recursion problem06/21/08
CLOSED http://bugs.python.org/issue3165created  cuerty
   patch   

Make conversions from long to float correctly rounded.   06/21/08
   http://bugs.python.org/issue3166created  marketdickinson   
   patch   

math test fails on Solaris 1006/21/08
   http://bugs.python.org/issue3167created  MrJean1   
   

cmath test fails on Solaris 10

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-27 Thread Guido van Rossum

On Thu, Jun 26, 2008 at 3:22 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 26, 2008 at 8:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>
>> So you're saying py.test needs to be fixed? Fine with me, but then I
>> don't understand why you bothered bringing it up here instead of
>> fixing it (or reporting to the py.test maintainers, I don't know if
>> you're one or not).
>>
>
> no, I'm not. Just wanted to point out, that this ticket/patch does not
> solve the django issue.
> (this is what I first thought it would do).

I'm still missing details.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-27 Thread Guido van Rossum

On Thu, Jun 26, 2008 at 5:33 PM,  <[EMAIL PROTECTED]> wrote:
> OK, fair enough.  Taking a step back, I was pushing this really hard because
> to *me*, it seems like dealing with the influx of bug reports after the fact
> is an unreasonable amount of additional work, whereas immediate reverts are
> just an occasional, temporary inconvenience. Based on my experience, "We'll
> deal with the reports as they come in" sounds like "no".

No, that's not how it was intended. I'd rather hear you tell us about
your pain than telling us how to fix it.

> I think since the last time we had a similar conversation, other Twisted
> developers have been fairly diligent in reporting bugs.  (In the time
> they've been reporting Python bugs, I've mostly been planning a wedding.
> Others who have survived it tell me that eventually, this process ends...
> and then I should be participating more directly.)  I'll try to step up that
> feeback loop and get other projects involved.  I hope I am wrong about
> generating an unreasonable amount of work.

Again, I'd much rather see you generate a huge pile of work for us in
the form of specific bug reports than trying to tell us how to change
our process.

> Thanks.  I appreciate it; an increased emphasis on 3rd party code being
> broken is really what I was looking for.  This is fine with me.  I mean,
> whatever your decision is, I'm going to have to live with it :), but in
> either case, we have to be looking for bugs and helping to investigate them.
>  On my end of things I guess it's not going to make much difference.

Right. The beta period is the time to pay attention to 3rd party
breakage. While we won't make any specific promises, we're taking 3rd
party code breakage very seriously and, depending on the specifics, it
can hold up a release. It just won't be automatic; many 3rd party
breakages are most easily fixed by making small adjustments to the 3rd
party code involved. (Imagine a 3rd party package still using string
exceptions.)

.
.
.

On Thu, Jun 26, 2008 at 6:13 PM,  <[EMAIL PROTECTED]> wrote:
> For the record, "automatic revert" does not mean "drop all other work". The
> changeset's still there.  It's still in the revision history.  It can easily
> be applied to anybody's working copy.  It can easily be put into a branch.
>  It can be automatically re-merged later.  I do all of these things all the
> time, and I was *not* intending to suggest that any 3rd-party breakage
> should cause a code freeze or anything even remotely like that.

Still, a revert often holds up other work that depends on the reverted
change. I expect that in most cases, finding the problem and applying
a fix is much less of a burden for the core developer team as a whole
than rolling back, working on a fix, and re-applying. I also expect
that the policy of semi-automated merges from 2.6 into 3.0 would make
a revert even more work, and more likely to cause second-order problem
in the 3.0 branch.

>>> (...) it would have been easier to
>>> convince a Twisted developer to do the work it to keep the community
>>> buildbot green rather than to make it a bit less red.
>>
>> Why? That sounds like it's a problem with the psychology of the
>> Twisted developers.
>
> I hardly think it's unique to us.  TDD test runners typically only know 2
> colors and 2 states: "passed" and "fails".  Once you're in the "fail" state,
> you tend to accumulate more failures; there's a much bigger bang for your
> buck.  Better tools with nicer interfaces would let you easily mark
> individual tests as "usually intermittent" or something and make it a
> "slightly dirty green" or something, but we don't have those.  The move from
> "red" to "green" is much more psychologically significant to just about
> anyone I know than the move from "red but 14 failures" to "red but 12
> failures".

Still sounds like perhaps you're too much focused on the "green bar".
I know this is encouraged by XP, but I don't want to have a religious
debates about whether XP is the right development model for Python.
(The time would be better spent on improving the buildbot reporting!)

> Despite the idea's origins in a now-highly-controversial book on
> criminology, this is often referred to in XP discussion circles (wikis and
> the like) as the "fix broken windows" collaboration pattern.  I notice this
> in lots of other areas of my life; a little pile of papers tends to become a
> big pile of papers, the first dent in a car makes the driver a little less
> careful, and so on.

For me, with that first dent comes the realization that it's really
not worth it to obsess over scratches, and that makes me a more
relaxed and hence *better* (because less stressed) driver. :-)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Guido van Rossum

Now that I've learned about the hex float format supported by C++ and
Java, I wonder if it wouldn't be better to support conversion to and
from that format and nothing else.

E.g.

>>> math.tohex(3.14)
'0x1.91eb851eb851fp+1'
>>> math.fromhex('0x1.91eb851eb851fp+1')
3.1401
>>>

BTW I am still hoping to be able the output of the second command to
just "3.14" but the tracker issue for that
(http://bugs.python.org/issue1580) is stuck on trying to decide
whether it's okay to have repr() occasionally return a string
that doesn't convert to the exact same value on another platform. (My
preferred approach would ensure that it does convert to the same value
on the same platform, because that's how I'd compute it.) Perhaps the
existance of an unambiguous hex format that is also interchangeable
with Java and C (and presumably C++) would alleviate that concern.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Guido van Rossum

PS. I can't get excited about having support for this in %-style
format strings (and even less so now %a already means "call ascii()").
It would be easy enough to add support for it to float.__format__()
though.

On Fri, Jun 27, 2008 at 12:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.
>
> E.g.
>
 math.tohex(3.14)
> '0x1.91eb851eb851fp+1'
 math.fromhex('0x1.91eb851eb851fp+1')
> 3.1401

>
> BTW I am still hoping to be able the output of the second command to
> just "3.14" but the tracker issue for that
> (http://bugs.python.org/issue1580) is stuck on trying to decide
> whether it's okay to have repr() occasionally return a string
> that doesn't convert to the exact same value on another platform. (My
> preferred approach would ensure that it does convert to the same value
> on the same platform, because that's how I'd compute it.) Perhaps the
> existance of an unambiguous hex format that is also interchangeable
> with Java and C (and presumably C++) would alleviate that concern.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] repeated keyword arguments

2008-06-27 Thread tomer filiba

the following code works on python 2.5:

>>> def f(**kwargs):
... print kwargs
...
>>> f(a=5,b=7,a=8)
{'a': 8, 'b': 7}
>>>

but fails on python2.4, saying that "a" is given twice.
is this a bug or a feature?


-tomer
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Guido van Rossum

Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably due
to the switch to the  new AST-based compiler. Can you file a bug? I
think we should leave 2.5 alone (too much risk of breaking code) but
fix it in 2.6 and 3.0 if we can.

--Guido

On Fri, Jun 27, 2008 at 12:07 PM, tomer filiba <[EMAIL PROTECTED]> wrote:
> the following code works on python 2.5:
>
 def f(**kwargs):
> ... print kwargs
> ...
 f(a=5,b=7,a=8)
> {'a': 8, 'b': 7}

>
> but fails on python2.4, saying that "a" is given twice.
> is this a bug or a feature?
>
>
> -tomer
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Chris AtLee

On Fri, Jun 27, 2008 at 11:40 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> I notice that there is some work being done on urllib / urllib2 for
>> python 2.6/3.0.  One thing I've always missed in urllib/urllib2 is the
>> facility to encode POST data as multipart/form-data.  I think it would
>> also be useful to be able to stream a POST request to the remote
>> server rather than having requiring the user to create the entire POST
>> body in memory before starting the request.  This would be extremely
>> useful when writing any kind of code that does file uploads.
>>
>> I didn't see any recent discussion about this so I thought I'd ask
>> here: do you think this would make a good addition to the new urllib
>> package?
>
> I think it would be very helpful.  I'd separate the two things,
> though; you want to be able to format a set of values as
> "multipart/form-data", and do various things with that resulting
> "document", and you want to be able to stream a POST (or PUT) request.

How about if the function that encoded the values as "multipart/form-data"
was able to stream data to a POST (or PUT) request via an iterator that
yielded chunks of data?

def multipart_encode(params, boundary=None):
"""Encode ``params`` as multipart/form-data.

``params`` should be a dictionary where the keys represent parameter names,
and the values are either parameter values, or file-like objects to
use as the parameter value.  The file-like object must support the .read(),
.seek(), and .tell() methods.

If ``boundary`` is set, then it as used as the MIME boundary.  Otherwise
a randomly generated boundary will be used.  In either case, if the
boundary string appears in the parameter values a ValueError will be
raised.

Returns an iterable object that will yield blocks of data representing
the encoded parameters."""

The file objects need to support .seek() and .tell() so we can determine
how large they are before including them in the output.  I've been trying
to come up with a good way to specify the size separately so you could use
unseekable objects, but no good ideas have come to mind.  Maybe it could
look for a 'size' attribute or callable on the object?  That seems a bit
hacky...

A couple helper functions would be necessary as well, one to generate
random boundary strings that are guaranteed not to collide with file data,
and another function to calculate the total size of the encoding to be used
in the 'Content-Length' header in the main HTTP request.

Then we'd need to change either urllib or httplib to support iterable
objects in addition to the regular strings that it currently uses.

Cheers,
Chris
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Steve Holden


So we wait until they port their code to 2.6 to break it?

regards
 Steve

Guido van Rossum wrote:

Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably due
to the switch to the  new AST-based compiler. Can you file a bug? I
think we should leave 2.5 alone (too much risk of breaking code) but
fix it in 2.6 and 3.0 if we can.

--Guido

On Fri, Jun 27, 2008 at 12:07 PM, tomer filiba <[EMAIL PROTECTED]> wrote:

the following code works on python 2.5:


def f(**kwargs):

... print kwargs
...

f(a=5,b=7,a=8)

{'a': 8, 'b': 7}
but fails on python2.4, saying that "a" is given twice.
is this a bug or a feature?


-tomer

___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/guido%40python.org









--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

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

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Benjamin Peterson

On Fri, Jun 27, 2008 at 2:11 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably due
> to the switch to the  new AST-based compiler. Can you file a bug? I
> think we should leave 2.5 alone (too much risk of breaking code) but
> fix it in 2.6 and 3.0 if we can.

I think code that uses this is probably already quite broken in some
fundamental way and putting the fix in 2.5 isn't much of a risk.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread David Wolever


On 27-Jun-08, at 6:23 PM, Benjamin Peterson wrote:
On Fri, Jun 27, 2008 at 2:11 PM, Guido van Rossum  
<[EMAIL PROTECTED]> wrote:
Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably  
due

to the switch to the  new AST-based compiler. Can you file a bug? I
think we should leave 2.5 alone (too much risk of breaking code) but
fix it in 2.6 and 3.0 if we can.


I think code that uses this is probably already quite broken in some
fundamental way and putting the fix in 2.5 isn't much of a risk.


I don't have 2.4 handy to test it, but it is more likely that a  
keyword and dictionary are passed, both containing the same item:

>>> f(a=3, **{'a': 4})

Would that be a potential risk?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Scott Dial


David Wolever wrote:
I don't have 2.4 handy to test it, but it is more likely that a keyword 
and dictionary are passed, both containing the same item:

 >>> f(a=3, **{'a': 4})

Would that be a potential risk?


Python 2.4.3
>>> f(a=3, **{'a': 4})
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: f() got multiple values for keyword argument 'a'

Python 2.5
>>> f(a=3, **{'a': 4})
TypeError: f() got multiple values for keyword argument 'a'

The regression is purely in the way an argument list is reduced to a 
dictionary.


--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Fred Drake


On Jun 27, 2008, at 5:23 PM, Benjamin Peterson wrote:

I think code that uses this is probably already quite broken in some
fundamental way and putting the fix in 2.5 isn't much of a risk.


I suspect the risk has more to do with breaking something else in  
Python than in breaking 3rd-party code in this case.


I think it should be fixed for 2.5 as well, myself.


  -Fred

--
Fred Drake   




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

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Mark Dickinson

On Fri, Jun 27, 2008 at 8:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.
>
> E.g.
>
 math.tohex(3.14)
> '0x1.91eb851eb851fp+1'
 math.fromhex('0x1.91eb851eb851fp+1')
> 3.1401

This would certainly be enough for me, though I think there's still
some educational value in having binary output available.  But
that's just a matter of substituting a four-bit binary string for
each hexadecimal digit (or learning to read hexadecimal as
though it were binary).

In fromhex, what would be done with a string that gives more
hex digits than the machine precision can support?  An obvious
answer is just to round to the nearest float, but since part of the
point of hex floats is having a way to specify a given value
*exactly*, it might make more sense to raise an exception
rather than changing the value by rounding it.

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Scott Dial


Scott Dial wrote:
The regression is purely in the way an argument list is reduced to a 
dictionary.


To further elaborate:

Python 2.4:
>>> import dis
>>> dis.dis(compile('f(a=3, b=1, a=4)', '', 'eval'))
Traceback (most recent call last):
  File "", line 1, in ?
SyntaxError: duplicate keyword argument

Python 2.5:
>>> import dis
>>> dis.dis(compile('f(a=3, b=1, a=4)', '', 'eval'))
  1   0 LOAD_NAME0 (f)
  3 LOAD_CONST   0 ('a')
  6 LOAD_CONST   1 (3)
  9 LOAD_CONST   2 ('b')
 12 LOAD_CONST   3 (1)
 15 LOAD_CONST   0 ('a')
 18 LOAD_CONST   4 (4)
 21 CALL_FUNCTION  768
 24 RETURN_VALUE

The old compiler checked for this, but the AST-based compiler just 
blindly compiles the entire keyword argument sequence.


-Scott

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Benjamin Peterson

On Fri, Jun 27, 2008 at 5:00 PM, Scott Dial
<[EMAIL PROTECTED]> wrote:
>
> The old compiler checked for this, but the AST-based compiler just blindly
> compiles the entire keyword argument sequence.

The new compiler will check for it when my patch on the issue 3219 is applied.


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Mark Dickinson

On Fri, Jun 27, 2008 at 8:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.

By the way, this particular format is also recommended by the draft versions
of IEEE 754r that I've seen:  section 7.12.2 of draft version 1.2.5
(this is publicly
available---there's a link from the wikipedia 754r page) says:

"""Implementations supporting binary formats shall provide conversions
between all supported internal binary
formats and external hexadecimal character sequences. External
hexadecimal character sequences for finite
numbers are of the form specified by C99 subclauses:
6.4.4.2 floating constants,
20.1.3 strtod,
7.19.6.2 fscanf (a, e, f, g), and
7.19.6.1 fprintf (a, A)."""

More recent 754r drafts spell the grammar out explicitly instead of
referring to C99,
and weaken the 'shall' (i.e., 'is required to') to a 'should' ('is
recommended to').

Mark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Guido van Rossum

On Fri, Jun 27, 2008 at 2:23 PM, Benjamin Peterson
<[EMAIL PROTECTED]> wrote:
> On Fri, Jun 27, 2008 at 2:11 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably due
>> to the switch to the  new AST-based compiler. Can you file a bug? I
>> think we should leave 2.5 alone (too much risk of breaking code) but
>> fix it in 2.6 and 3.0 if we can.
>
> I think code that uses this is probably already quite broken in some
> fundamental way and putting the fix in 2.5 isn't much of a risk.

No, it could just be a harmless typo in a long argument list. I really
don't want to break code that is apparently working as part of an
upgrade from 2.5.2 to 2.5.3. I want people to be completely fearless
when it comes to such an upgrade: they should be able to just install
it without having to think about testing anything, just like most
people routinely install a new minor Linux upgrade pushed by their
distribution.

2.6 is a different story, everyone knows they have to do testing
before deciding it's safe to upgrade from 2.x to 2.(x+1).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Guido van Rossum

Yes.

On Fri, Jun 27, 2008 at 2:18 PM, Steve Holden <[EMAIL PROTECTED]> wrote:
> So we wait until they port their code to 2.6 to break it?
>
> regards
>  Steve
>
> Guido van Rossum wrote:
>>
>> Sounds like a regression in 2.5 (and in 2.6, and in 3.0). Probably due
>> to the switch to the  new AST-based compiler. Can you file a bug? I
>> think we should leave 2.5 alone (too much risk of breaking code) but
>> fix it in 2.6 and 3.0 if we can.
>>
>> --Guido
>>
>> On Fri, Jun 27, 2008 at 12:07 PM, tomer filiba <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> the following code works on python 2.5:
>>>
>> def f(**kwargs):
>>>
>>> ... print kwargs
>>> ...
>>
>> f(a=5,b=7,a=8)
>>>
>>> {'a': 8, 'b': 7}
>>> but fails on python2.4, saying that "a" is given twice.
>>> is this a bug or a feature?
>>>
>>>
>>> -tomer
>>>
>>> ___
>>> Python-Dev mailing list
>>> [email protected]
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe:
>>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>
>>>
>>
>>
>>
>
>
> --
> Steve Holden+1 571 484 6266   +1 800 494 3119
> Holden Web LLC  http://www.holdenweb.com/
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Terry Reedy




Mark Dickinson wrote:




math.tohex(3.14)

'0x1.91eb851eb851fp+1'

math.fromhex('0x1.91eb851eb851fp+1')

3.1401


How about just one self-inverse method .hex?
.hex(float/hexstring) returns corresponding hexstring/float

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

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Guido van Rossum

On Fri, Jun 27, 2008 at 2:54 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Jun 27, 2008, at 5:23 PM, Benjamin Peterson wrote:
>>
>> I think code that uses this is probably already quite broken in some
>> fundamental way and putting the fix in 2.5 isn't much of a risk.
>
> I suspect the risk has more to do with breaking something else in Python
> than in breaking 3rd-party code in this case.
>
> I think it should be fixed for 2.5 as well, myself.

Let me clarify why I want to be so careful with this.

If there is code that was expected to work but due to a bug in our
code raises an exception, it's generally safe to fix this: people who
ran into the issue found that their code didn't work, used a
work-around, and that's the end of the story.

But if there is code that was expected to *break* but due to a bug in
our code *doesn't* raise an exception, people can very well have
harmless occurrences of such code, and never noticed. Maybe their code
is "broken" in the sense that it doesn't produce the correct result,
but it may well be in a "don't care" way -- but if an upgrade suddenly
starts raising the exception, they are likely to get unhandled
exceptions where before they had none. This is particularly annoying
when the author of the program that breaks is not the user of the
program, to whose machine the upgrade was applied.

In such cases I think it's better not to introduce new exceptions in
point-point releases.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Guido van Rossum

On Fri, Jun 27, 2008 at 2:54 PM, Mark Dickinson <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 27, 2008 at 8:02 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Now that I've learned about the hex float format supported by C++ and
>> Java, I wonder if it wouldn't be better to support conversion to and
>> from that format and nothing else.
>>
>> E.g.
>>
> math.tohex(3.14)
>> '0x1.91eb851eb851fp+1'
> math.fromhex('0x1.91eb851eb851fp+1')
>> 3.1401
>
> This would certainly be enough for me, though I think there's still
> some educational value in having binary output available.  But
> that's just a matter of substituting a four-bit binary string for
> each hexadecimal digit (or learning to read hexadecimal as
> though it were binary).

If it's educational it can be left as an exercise for the reader. :-)

> In fromhex, what would be done with a string that gives more
> hex digits than the machine precision can support?  An obvious
> answer is just to round to the nearest float, but since part of the
> point of hex floats is having a way to specify a given value
> *exactly*, it might make more sense to raise an exception
> rather than changing the value by rounding it.

Whatever Java and C99 do.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Guido van Rossum

On Fri, Jun 27, 2008 at 3:59 PM, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
>
> Mark Dickinson wrote:
>
>>>
>> math.tohex(3.14)
>>>
>>> '0x1.91eb851eb851fp+1'
>>
>> math.fromhex('0x1.91eb851eb851fp+1')
>>>
>>> 3.1401
>
> How about just one self-inverse method .hex?
> .hex(float/hexstring) returns corresponding hexstring/float

That seems to be a misplaced attempt at economy, obscuring the intent
from the reader.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] r64424 - in python/trunk:Include/object.h Lib/test/test_sys.py Misc/NEWSObjects/intobject.c Objects/longobject.c Objects/typeobject.cPython/bltinmodule.c

2008-06-27 Thread Martin v. Löwis

> Now that I've learned about the hex float format supported by C++ and
> Java, I wonder if it wouldn't be better to support conversion to and
> from that format and nothing else.

I would be fine with that, and prefer it over the original change.

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

Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Bill Janssen

All sounds reasonable to me.

Bill

> On Fri, Jun 27, 2008 at 11:40 AM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> I notice that there is some work being done on urllib / urllib2 for
> >> python 2.6/3.0.  One thing I've always missed in urllib/urllib2 is the
> >> facility to encode POST data as multipart/form-data.  I think it would
> >> also be useful to be able to stream a POST request to the remote
> >> server rather than having requiring the user to create the entire POST
> >> body in memory before starting the request.  This would be extremely
> >> useful when writing any kind of code that does file uploads.
> >>
> >> I didn't see any recent discussion about this so I thought I'd ask
> >> here: do you think this would make a good addition to the new urllib
> >> package?
> >
> > I think it would be very helpful.  I'd separate the two things,
> > though; you want to be able to format a set of values as
> > "multipart/form-data", and do various things with that resulting
> > "document", and you want to be able to stream a POST (or PUT) request.
> 
> How about if the function that encoded the values as "multipart/form-data"
> was able to stream data to a POST (or PUT) request via an iterator that
> yielded chunks of data?
> 
> def multipart_encode(params, boundary=None):
> """Encode ``params`` as multipart/form-data.
> 
> ``params`` should be a dictionary where the keys represent parameter 
> names,
> and the values are either parameter values, or file-like objects to
> use as the parameter value.  The file-like object must support the 
> .read(),
> .seek(), and .tell() methods.
> 
> If ``boundary`` is set, then it as used as the MIME boundary.  Otherwise
> a randomly generated boundary will be used.  In either case, if the
> boundary string appears in the parameter values a ValueError will be
> raised.
> 
> Returns an iterable object that will yield blocks of data representing
> the encoded parameters."""
> 
> The file objects need to support .seek() and .tell() so we can determine
> how large they are before including them in the output.  I've been trying
> to come up with a good way to specify the size separately so you could use
> unseekable objects, but no good ideas have come to mind.  Maybe it could
> look for a 'size' attribute or callable on the object?  That seems a bit
> hacky...
> 
> A couple helper functions would be necessary as well, one to generate
> random boundary strings that are guaranteed not to collide with file data,
> and another function to calculate the total size of the encoding to be used
> in the 'Content-Length' header in the main HTTP request.
> 
> Then we'd need to change either urllib or httplib to support iterable
> objects in addition to the regular strings that it currently uses.
> 
> Cheers,
> Chris
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/janssen%40parc.com

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

Re: [Python-Dev] Disable tests in unittest (issue3202)

2008-06-27 Thread Jonathan Lange

On Fri, Jun 27, 2008 at 4:57 AM, Justin Mazzola Paluska <[EMAIL PROTECTED]> 
wrote:
> I wasn't aware of bzrlib's extentions to unittest — many of them,
> including KnownFailure, TestSkipped,
> bzrlib.test.ExtendedTestResult.expectFailure, and the sundry list of
> bzrlib.test.TestCase.assert* look useful enough to belong in the
> standard library.
>

I agree 100%. Twisted came up with some of the same things
independently, and for a lot of things, we've stolen bzrlib's ideas.

I think I've filed a couple of tickets with patches along these lines.
I'll try to get my act in gear and finish the rest of the patches to
unittest and get them landed.

jml
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Jeff Hall

That's all fine and good but in this case there may be "stealth errors". If
the user/programmer is expecting the first value to hold but instead

On Fri, Jun 27, 2008 at 7:03 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> On Fri, Jun 27, 2008 at 2:54 PM, Fred Drake <[EMAIL PROTECTED]> wrote:
> > On Jun 27, 2008, at 5:23 PM, Benjamin Peterson wrote:
> >>
> >> I think code that uses this is probably already quite broken in some
> >> fundamental way and putting the fix in 2.5 isn't much of a risk.
> >
> > I suspect the risk has more to do with breaking something else in Python
> > than in breaking 3rd-party code in this case.
> >
> > I think it should be fixed for 2.5 as well, myself.
>
> Let me clarify why I want to be so careful with this.
>
> If there is code that was expected to work but due to a bug in our
> code raises an exception, it's generally safe to fix this: people who
> ran into the issue found that their code didn't work, used a
> work-around, and that's the end of the story.
>
> But if there is code that was expected to *break* but due to a bug in
> our code *doesn't* raise an exception, people can very well have
> harmless occurrences of such code, and never noticed. Maybe their code
> is "broken" in the sense that it doesn't produce the correct result,
> but it may well be in a "don't care" way -- but if an upgrade suddenly
> starts raising the exception, they are likely to get unhandled
> exceptions where before they had none. This is particularly annoying
> when the author of the program that breaks is not the user of the
> program, to whose machine the upgrade was applied.
>
> In such cases I think it's better not to introduce new exceptions in
> point-point releases.
>
> --
> --Guido van Rossum (home page: 
> http://www.python.org/~guido/
> )
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/hall.jeff%40gmail.com
>



-- 
Haikus are easy
Most make very little sense
Refrigerator
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Jeff Hall

oops... baby jumped in my lap... i pretty much said it all though... I think
the error of the software functioning incorrectly may necessitate the
patch... I certainly understand Guido's concern, however.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-27 Thread Nick Coghlan


Guido van Rossum wrote:

On Thu, Jun 26, 2008 at 3:22 PM, Ralf Schmitt <[EMAIL PROTECTED]> wrote:

On Thu, Jun 26, 2008 at 8:45 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

So you're saying py.test needs to be fixed? Fine with me, but then I
don't understand why you bothered bringing it up here instead of
fixing it (or reporting to the py.test maintainers, I don't know if
you're one or not).


no, I'm not. Just wanted to point out, that this ticket/patch does not
solve the django issue.
(this is what I first thought it would do).


I'm still missing details.



I'm going to spend some time looking into this this weekend (issue 
assigned appropriately. Getting it working again shouldn't be too bad 
(just revert the relevants bits to their 2.5 equivalents) - the tricky 
part is going to be keeping the warning of the associated change to the 
semantics in 3.0.


(I'll also take a look at 3.0 to make sure the relevant test case from 
the tracker issue works properly there)


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Nick Coghlan


Chris AtLee wrote:

Then we'd need to change either urllib or httplib to support iterable
objects in addition to the regular strings that it currently uses.


Chris,

To avoid losing these ideas, could you add them to the issue tracker as 
feature requests? It's too late to get them into 2.6/3.0 but they may 
make good additions for the next release cycle.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Greg Ewing


tomer filiba wrote:


 >>> def f(**kwargs):
... print kwargs
...
 >>> f(a=5,b=7,a=8)
{'a': 8, 'b': 7}
 >>>


I can't think of any reason why one would need to be
able to write such code, or even want to.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] urllib, multipart/form-data encoding and file uploads

2008-06-27 Thread Greg Ewing


Chris AtLee wrote:

One thing I've always missed in urllib/urllib2 is the
facility to encode POST data as multipart/form-data.


I second that, having had to reinvent it a couple of
times recently. It seems like an obvious thing to want
to do, and it's surprising to find it's not supported.

--
Greg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Steven D'Aprano

On Sat, 28 Jun 2008 11:17:10 am Greg Ewing wrote:
> tomer filiba wrote:
> >  >>> def f(**kwargs):
> >
> > ... print kwargs
> > ...
> >
> >  >>> f(a=5,b=7,a=8)
> >
> > {'a': 8, 'b': 7}
>
> I can't think of any reason why one would need to be
> able to write such code, or even want to.

It would be nice to be able to do this:

defaults = dict(a=5, b=7)
f(**defaults, a=8)  # override the value of a in defaults

but unfortunately that gives a syntax error. Reversing the order would 
override the wrong value. So as Python exists now, no, it's not 
terribly useful. But it's not inherently a stupid idea.


-- 
Steven
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] repeated keyword arguments

2008-06-27 Thread Scott Dial


Steven D'Aprano wrote:

It would be nice to be able to do this:

defaults = dict(a=5, b=7)
f(**defaults, a=8)  # override the value of a in defaults


I can't help but think that would be difficult coding convention to use. 
However, I'm considerably less bothered by:


def f_with_defaults(**kw):
defaults = dict(a=5, b=7)
defaults.update(kw)
return f(**defaults)
f_with_default(a=8)

The only way f(**defaults, a=8) would be useful is if it happens a lot, 
and in that case, it's just as good of a candidate for being made into a 
function itself. I see this pattern all the time, and given that 
"f_with_defaults" probably has some semantic meaning, it probably would 
be nice to give it it's own name ("g").


Just my 2 cents.

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

41 matches

Mail list logo