utton on GUI.
>
> Could you please send the syntax for the same?
>
This list is for the development *of* Python. Your question would be
better addressed to comp.lang.python (python-list at python dot org).
There are many people on that list who will be able to help you.
regards
Steve
-
naming? I would think that "odict" or
> "ordereddict" would be more consistent with other collections names
> especially "defaultdict".
>
Surely that's just a thinko in the subject line? The PEP specifies
"ordered dictionary" and nobody has been ta
istent and the new ordered dict version would
>> go by
>> the name "OrderedDict".
>
> OK.
>
>> PS.: so is datetime.datetime a builtin then? :)
>
> Another historic accident. Like socket.socket. :-(
>
A pity this stuff wasn't addressed for 3.0. Way
the transition was being handled. In this case the old
> names and simply subclass the new names and have no issues with old code.
>
There's also no reason why someone couldn't write a pickle updater for
when such problems do rear their ugly heads.
regards
Steve
with pink polka dots, but I'm
> starting to appreciate why others are insisting on pink with green polka
> dots ;-)
>
This will be no surprise to those who have seen the many discussions on
ordered dicts that c.l.py has spawned over the years.
regards
Steve
--
Steve Holden+1 5
> documentation, but I do realise it will take a lot of hands-on learning
> first. Trying to grok the discussions on this list seems like a big part
> of that.
>
Just dive in. We'll savage you when you get out of line :^).
Seriously, as long as it's about development *of* r
gt;
> Am still +1 on painting the class green with pink polka dots, but I'm
> starting to appreciate why others are insisting on pink with green polka
> dots ;-)
>
historydict?
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC
at this "API" is designed to work in 2.5 as well. :-)
>
>> But why? The argument I made had the objective of minimizing developer
>> effort. What's the objective of maintaining backward compatibility within
>> the 2.6 series in this case (sorry if it appe
that someone could turn
> into a PEP relatively straightforwardly. Deal?
>
>
> Will any or all of you be at PyCon? I'd be willing to put in the extra
> work to turn your notes into a PEP.
>
OPEN SPACE!
--
Steve Holden+1 571 484 6
Jesse Noller wrote:
[...]I'll take it from anyone.
>
And we can *quote* you on that?
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.p
are included.
>
Perhaps we could encourage more "jumbo" distributions, like Enthought's
and ActiveState's. I suspect many people would rather be able to
maintain their Python functionality as a single product.
regards
Steve
--
Steve Holden +1 571 484 6266 +1
any
> more of these!
Yes, well done, Benjamin. Barry Warsaw is walking with a spring in his
steps again ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to
for a while that there's much less support code available
for the 3.x version. The transition to 3.x is really only just beginning.
regards
Steve
John Wagner wrote:
>
>
> -- Forwarded message --
> From: ** <mailto:[email protected]>>
> Date
ther Python modules will give you a single analyzable module
tree. You don't even have to distribute the GUI if you don't want ...
So I don't see "jumbo" as replacing "batteries included". More like
"comes with 14v 300AH accumulator and support for domain name
from stdlib references.
Why not just put a section in both places that says "can't be bothered
to spell this out right now" and put a URL in referring to this thread
on Google ... that appears to have been the traditional approach to
import semantics :)
regards
Steve
--
Stev
a good
> mentor for it?
>
We also need projects for people who may want to do some coding and then
just walk away - the SoC experience might teach them that programming
isn't for them ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1
contact
> info on the wiki so potential students can hash out the details with
> them before applying.
>
Realistically I am not sure I will have time to mentor, but if you need
any help from the PSF please feel free to get in touch. Thanks for
taking this challenging role up on behalf of
or coding is in-line. If you don't like the appearance of
> the output, the module is unusable. This is likely a two to
> three day project, easy and fun.
>
That makes it a much better candidate for GHOP that SoC, which requires
projects with a little more meat on them.
re
ent would be some enthusiasm from the
developer team for mobilizing such a potential source of assistance.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.org/
equirements and Python can't
satisfy them all without getting more complex.
Some people want an "all batteries and kitchen sink included" distro
that they can treat as a single component for configuration control
purposes. Others, like you, want the libraries to be separated out to
al
> superior alternative to".
>
> [2] If "your users" include Debian and RHEL users, you may find that
> they are not so happy with yet more PMS.
>
Seems to me that while all this is fine for developers and Python users
it's completely unsatisfactory for people who j
ystems independent of their distribution's packaging
standard. As time goes by, however, and the Lunix installed base
continues to grow, the majority of users will expect to rely on the
standard installation mechanisms of their distribution, and that will
never be setuptools or distutils.
regar
somewhat to
yield expr for x from X
The idea is that x should be a a bound variable in expr, but the "expr
for x" could be optional to yield the existing proposal as a degenerate
case.
> Also [...]
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LL
"end users" won't wish to install individual Python modules
this argument may have had some merit, but I personally thought the
criticism unjustified since Mike's technique gave a uniform install
procedure for everything.
I don't think anyone was suggesting that py2exe woul
rson to request a
> "passing of judgement" from someone with more experience/authority? Post
> to python-dev? Given such a mechanism, I think I would be comfortable
> with the current workflow, with the expectation that I would need to
> call for assistance less and less freque
The pyjamas author seems to have a different
> opinion about installing stuff into /usr without working with the system's
> packaging mechanism:
>
> http://bugs.python.org/setuptools/issue63
>
> I don't understand how that can possibly be manageable.
>
Note
t.p_print and ...
That way madness lies. Besides which, what a terrific opportunity to
castigate the Py3k developers forever. Opportunities like that don't
come by every day ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800
Maybe of
you looked at the code you would find low-hanging fruit you could pick
for sensible use cases.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.org/
__
Guido van Rossum wrote:
[...] (There could be good reasons not to
> complexificate it this way too.)
>
You've been 'Mercanized. This is the most worstest English I have ever
seen you write.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 311
ile the "yield from" expression's
value comes from "outside" (the value passed to a .send() method call).
Please forgive this bear of very little brain. I suspect the
documentation will need to make this asymmetry more obvious still.
regards
Steve
--
Steve Holden
Module(__name__).filePath.parent().listdir()
>
> (and yes, this works with zip files)
Careful, Glyph. Nobody likes a smart-ass ;-)
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http:
mmer I ever
>> met.)
>
> But is his humility enough to cancel out Linus's attitude?
>
All the humility in the world pales besides Linus's attitude. But that's
probably just because we are all fools.
regards
Steve
--
Steve Holden
on't
>> fix it." :-)
>
> Anything using an exec
that can be done in some other (more pythonic way)
> is broken by definition ;-)
>
> Benjamin?
>
We've just had a fairly clear demonstration that small semantic changes
to the language can leave unexpected
s the big disadvantage of not being Microsoft-endorsed,
> though. In that sense, it feels very much like easy_install (which also
> does dependencies).
>
Not only that, but the Cygwin packaging system appears to be extremely
difficult to organize a package for.
regards
Steve
--
Steve H
hitespace in makefiles: only the fact that leading tabs were required
rather than just-any-old whitespace.
I guess some people just home in on things to complain about.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.c
suring that all
contributions to source are correctly logged against authors in a
traceable way.
regasds
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.org/
__
gt;
> You wrote a program to find the two smallest ints that would have a
> hash collision in the CPython set implementation? I'm impressed. And
> by impressed I mean frightened.
>
Given the two numbers in question (1, 2**16+1) I suspect this is the
result of an
>>
>>>>> print set([-1,6]).pop(), set([6,-1]).pop()
>> 6 -1
>
> Can't resist:
>
>>>> print set([-2,-1]).pop(), set([-1,-2]).pop()
> -1 -2
>
>>> a = 0.001
>>> b = 0.002
>>> print set([a, b]).pop(), set([b, a]).pop
the only ways to
store the messages are either as a monolithic bytes string that gets
parsed when the individual components are required or as a sequence of
components in the database's preferred encoding (if you want to keep the
original encoding most relational databases won't be able to he
Tony Nelson wrote:
> (email-sig added)
>
> At 08:07 -0400 04/09/2009, Steve Holden wrote:
>> Barry Warsaw wrote:
> ...
>>> This is an interesting question, and something I'm struggling with for
>>> the email package for 3.x. It turns out to be pretty
B adapters appears to require some fairly hairy escaping
of the data to make it usable with the cursor execute() method. IMHO you
shouldn't have to escape data that is passed for insertion via a
parameterized query.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
H
ter all, there isn't an example of a database that makes onerous the
> storing of email and other such byte-oriented data, and Python's email
> package has no need for workarounds in that area.
Create a table:
CREATE TABLE tst
(
id serial,
byt bytea,
PRIMARY KEY (id)
)
Oleg Broytmann wrote:
> On Thu, Apr 09, 2009 at 04:42:21PM -0400, Steve Holden wrote:
>> If I can't pass a 256-byte string into a BLOB and get it back without
>> anything like this happening then there's *something* in the chain that
>> makes the database useless
EASE EMAIL ME DIRECTLY (or Cc me on your list replies) to
make sure I get your information.
Thanks!
regards
Steve
Original Message
Subject: RE: Support for Python: Windows Buildbots
Date: Tue, 7 Jul 2009 08:52:10 -0700
From: Tom Hanrahan
For the purposes of providing MSDN lice
Christian Heimes wrote:
> Steve Holden wrote:
>> Devs:
>>
>> I've been in correspondence with Microsoft about the provision of
>> software, and it transpires that if you want to support Windows better
>> Microsoft will be quite liberal about licensing: they wi
I sent fourteen requests for licenses in to Microsoft. I've asked them
to let me know which they grant (since they may choose to limit the
number) and will inform you all personally when I hear their decision.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holde
e dev list right now I'd
appreciate direct Cc's.
regards
Steve
PS: If any further core developers need licenses, I plan to apply to
Microsoft again in the new year. I'll be sending out a message then, I
don't intend to keep a waiting list.
--
Steve Holden +1 571 4
I am interested in creating a patch to make deleting elements from the front of
Python list work in O(1) time by advancing the ob_item pointer.
The patch will probably be rejected, but I would like to try it anyway as an
exercise in digging into the CPython source, and working through the proces
--- On Mon, 1/25/10, Daniel Stutzbach wrote:
> FWIW, for a long-running FIFO queue, it's critical to
> release some of the memory along the way, otherwise the
> amount of wasted memory is unbounded.
>
Somebody implementing a long-running FIFO queue should actually be using deque
instead of lis
From: Raymond Hettinger
> On Jan 25, 2010, at 11:22 AM, Steve Howell
> wrote:
> I
> am interested in creating a patch to make deleting elements
> from the front of Python list work in O(1) time by advancing
> the ob_item pointer.
>
> +1 on doing whatever experiments yo
--- On Mon, 1/25/10, Benjamin Peterson wrote:
> 2010/1/25 Steve Howell :
> > I am interested in creating a patch to make deleting
> elements from the front
> > of Python list work in O(1) time by advancing the
> ob_item pointer.
>
> How about just using a deque?
Deq
> From: Raymond Hettinger
>
> On Jan 25, 2010, at 12:36 PM, Steve Howell wrote:
>
> >
> > Deque does not support all the operations that list
> does. It is also roughly twice as slow for accessing
> elements (I've measured it).
>
>
> ISTM that apps
--- On Mon, 1/25/10, Mike Klaas wrote:
> From: Mike Klaas
> > On Mon, Jan 25, 2010 at 1:22 PM, Steve Howell
> wrote:
> >>
> >> I haven't completely worked out the best strategy
> to eventually release
> >> the memory taken up by the pointers o
--- On Mon, 1/25/10, Benjamin Peterson wrote:
> From: Benjamin Peterson
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: [email protected]
> Date: Monday, January 25, 2010, 3:15 PM
> 2010/1/25 Steve Howell :
--- On Mon, 1/25/10, Christian Heimes wrote:
> From: Christian Heimes
> Michael Foord wrote:
> > How great is the complication? Making list.pop(0)
> efficient sounds like
> > a worthy goal, particularly given that the reason you
> don't use it is
> > because you *know* it is inefficient (so the
--- On Mon, 1/25/10, Nick Coghlan wrote:
> From: Nick Coghlan
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Michael Foord"
> Cc: "Christian Heimes" , [email protected]
> Date: Monday, January 25, 2010, 6:32 PM
> Michael Foord wrote:
> > On 26/01/2010 00:28,
I made enough of a patch to at least get a preliminary benchmark.
The program toward the bottom of this email runs over 100 times faster with my
patch. The patch still has a ways to go--I use a very primitive scheme to
reclaim orphan pointers (1000 at a time) and I am still segfaulting when
re
--- On Mon, 1/25/10, Steve Howell wrote:
> From: Steve Howell
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Michael Foord" , "Nick Coghlan"
>
> Cc: "Christian Heimes" , [email protected]
> Date: Monday, Janu
--- On Tue, 1/26/10, Stefan Behnel wrote:
> From: Stefan Behnel
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: [email protected]
> Date: Tuesday, January 26, 2010, 1:27 AM
> Michael Foord, 26.01.2010 01:14:
> > How great is the complication? Making list.pop(0)
>
> From: Nick Coghlan
>
> Steve, I suggest creating a new issue at bugs.python.org to
> track your
> proposal rather than sending diffs to the list.
Agreed. After sending out the second, still slightly broken diff, I realized
that I probably needed to read up on the process. Y
--- On Tue, 1/26/10, Daniel Stutzbach wrote:
> Just to be clear, when you say "all tests" do you
> mean "all of the list tests" or "the full
> Python test suite"?
>
The full suite, minus some tests that skipped on my platform. The last patch I
posted was broken on test_sys.py, but I have si
--- On Tue, 1/26/10, Antoine Pitrou wrote:
> From: Antoine Pitrou
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: [email protected]
> Date: Tuesday, January 26, 2010, 12:50 AM
> Terry Reedy
> udel.edu> writes:
> >
> > The idea that CPython should not be impro
The patch is now on Rietveld.
http://codereview.appspot.com/194083/show
I wsa getting HTTP errors for certain operations, like trying to publish
comments, but I am able to see the patch there.
Here is the issue tracker link:
http://bugs.python.org/issue7784
Here is a rough draft of a proposal
--- On Tue, 1/26/10, Guido van Rossum wrote:
> From: Guido van Rossum
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: "Nick Coghlan" , [email protected]
> Date: Tuesday, January 26, 2010, 11:17 AM
From: Guido van Rossum
>
> So here's how you can fix it: go to "Edit Issue" and change
> the
> "Base:" field to the following:
>
> http://svn.python.org/view/*checkout*/python/trunk/
>
I just deleted the issue altogether for now, since the preferred approach is to
use a pointer, and that's gon
> From: Guido van Rossum
> Steve Howell
> wrote:
> > It seems to me that the goal of keeping lists
> > super-compact from a memory standpoint is contradicted by
> > the code in list_resize that optimistically preallocates
> > extra memory on appends.
>
>
Please note that both Dino Viehland and Dave Fugate are now signed up to
make commits in the name of Microsoft Corporation. I believe this just
formalizes existing working relationships, but what would *I* know ...
Thanks, everybody. As you were.
regards
Steve
Original Message
--- On Wed, 1/27/10, Glenn Linderman wrote:
> As a newcomer to python, I must say that I wouldn't expect
> a list to be like an array. I'd expect it more to be
> like a list... many implementations of lists (linked lists,
> in particular) make it O(1) to add to the front or
> back. An array can
--- On Tue, 1/26/10, Cameron Simpson wrote:
> From: Cameron Simpson
> | The idea that CPython should not be improved because it
> would spoil
> | programmers strikes me as a thin, even desparate
> objection.
>
> Hey, I even used the word "thin" to describe my concern!
>
> My point was that I l
--- On Wed, 1/27/10, Daniel Stutzbach wrote:
> From: Daniel Stutzbach
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: [email protected]
> Date: Wednesday, January 27, 2010, 5:32 AM
> On Wed, Jan 27,
> 2010 at
--- On Tue, 1/26/10, Guido van Rossum wrote:
> From: Guido van Rossum
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: "Nick Coghlan" , [email protected]
> Date: Tuesday, January 26, 2010, 12:57 PM
--- On Wed, 1/27/10, John Arbash Meinel wrote:
> From: John Arbash Meinel
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: "Guido van Rossum" , "Nick Coghlan"
> , [email protected]
> Date: W
--- On Wed, 1/27/10, Daniel Stutzbach wrote:
> From: Daniel Stutzbach
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Steve Howell"
> Cc: "John Arbash Meinel" , [email protected]
> Date: Wednesday, January 27, 2010, 8:20 AM
--- On Wed, 1/27/10, Virgil Dupras wrote:
>
> Why is this thread still going? It seems to me that the
> case for this
> change is very weak. Lists, like dicts and tuples, are
> used
> *everywhere* and in *vast* quantities. Making them grow by
> 4 or 8
> bytes each for such a corner case can't be
--- On Wed, 1/27/10, Antoine Pitrou wrote:
> From: Antoine Pitrou
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: [email protected]
> Date: Wednesday, January 27, 2010, 6:15 AM
> Nick Coghlan
> gmail.com> writes:
> >
> > The big practical concern is actually t
--- On Wed, 1/27/10, Antoine Pitrou wrote:
> From: Antoine Pitrou
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: [email protected]
> Date: Wednesday, January 27, 2010, 12:41 PM
> Le mercredi 27 janvier 2010 à 11:49
> -0800, Steve Howe
--- On Wed, 1/27/10, Raymond Hettinger wrote:
> From: Raymond Hettinger
> Subject: Re: [Python-Dev] patch to make list.pop(0) work in O(1) time
> To: "Martin v. Löwis"
> Cc: "Steve Howell" , [email protected]
> Date: Wednesday, January 27, 2010, 1:49 P
> From: Antoine Pitrou
> gmail.com> writes:
> >
> > AFAICT, the performance of the proposal:
> >
> > * increases space requirements by a small fixed
> amount
>
> Well, given my proposal (assuming it turns out ok) it
> doesn't.
>
> > * s.append() performance slightly degraded.
>
> Why?
>
A
--- On Wed, 1/27/10, Raymond Hettinger wrote:
> From: Raymond Hettinger
> * the current design encourages people to use
> the right data structure for a given need. the
> proposed change makes the trades-off murky and
> implementation dependent.
Are you saying that the current slowness of
--- On Wed, 1/27/10, Alex Gaynor wrote:
>
> "Python lists implement a pretty useless data structure"
>
> It's very difficult for ideas to gain traction when they
> contain such
> useless, and obviously wrong, rhetoric. There's an
> enormous body of
> code out there that begs to disagree with
--- On Thu, 1/28/10, Josiah Carlson wrote:
> [...] in the decade+ that I've been using
> Python and
> needed an ordered sequence; lists were the right solution
> 99% of the
> time [...]
What do you think of LISP, and "car" in particular (apart from the stupidly
cryptic name)?
___
--- On Fri, 1/29/10, Stephen J. Turnbull wrote:
>
> > Lisp lists are really stacks
>
> No, they're really (ie, concretely) singly-linked
> lists.
>
> Now, stacks are an abstract data type, and singly-linked
> lists provide
> an efficient implementation of stacks. But that's not
> what link
/nonlocal/global with parallel capabilities. And it
might sometimes be useful for code inside a nested function to see
what variables are available at the enclosing level.
Steve Bonner
___
Python-Dev mailing list
[email protected]
http://mail.python.org
s mail in three weeks.
regards
Steve
[email protected] wrote:
> Hey all,
>
> This seems to happen whenever we do a new release (we've had a couple of
> emails to [email protected] about it since 2.6.5 was released). The
> main download page for Python has a broken link
Tres Seaver wrote:
> Steve Holden wrote:
>> Why is it unavoidable that the Mac build will languish behind others?
>> Are we supporting MacOs or aren't we? If we are, why isn't the creation
>> of the build a part of the release process?
>
>> Clearly it
e are always casts
> to force the issue.
>
Alas Python now supports so many number systems that there is no longer
a rational (in the non-numerical sense) ordering of the systems which
allows a linear progression from one to the next. It therefore behooves
us to consider the implications
eks.
>
> That is not surprising: none of the webmaster people would be able to
> answer the question. python-dev is indeed the right place to ask.
>
I thought I'd picked this thread off python-dev. What point am I not
understanding here?
regards
Steve
--
Steve Holden
to.
>
> Yes, ditto the MacPorts/Fink allergy.
>
> All we need is a script, right? The released branches should be built
> automatically every night anyway, just for regression testing.
>
> Perhaps we should take this up on Mac-Python?
>
Please do, and let me know
Michael Foord wrote:
> On 14/04/2010 06:13, Ned Deily wrote:
>> In article,
>> Steve Holden wrote:
>>
>>
>>> Why is it unavoidable that the Mac build will languish behind others?
>>> Are we supporting MacOs or aren't we? If we are, why
r.
>
> That is just my recollection, however - it may be out of date or wrong.
> Paul.
I spent some considerable effort last year ensuring the developer
community was well-supplied with MS developer licenses that give access
to any necessary tools. Was I wasting my time?
regards
Steve
--
S
en to if it didn't
exist"?
>> For alternative Python implementations which do not support `pyc`
>> files, the `__cached__` attribute may point to whatever information
>> makes sense. E.g. on Jython, this might be the `.class` file for the
>> module: `__pycach
some idea in order to get relevant results (e.g.,
> windows, windoze, window$, win32).
>
Yes, tight vocabulary control will lead to more consistent classifications.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://
ning pieces in the
> script, too, and no living person has that much expertise to write the
> script (perhaps there are one or two people, and they don't have the time).
>
I take it you don't mean to imply that there's a dead person somewhere
with the necessary expertise? [
the time).
>
> Well, God forbid they should ever be hit by a bus! This kind of thing
> needs to be written down.
>
+1
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/
Holden Web LLC htt
quot;authority" to recommend him.
In such an event (or if committers are too busy to action a promising
candidate) I don't see anything wrong with a candidate asking directly
(as long as they are prepared to put up with a semi-public discussion of
their application's merits).
reg
of presenting the content, though there is no thread subscription.
Google Groups have their disadvantages too. I personally dislike "web
forum" style interfaces.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
See PyCon Talks from Atlanta 2010 http://pycon.b
Brian Curtin wrote:
> Hi python-dev,
>
> The recent threads on builds/installers for Mac and Windows reminded me
> of Steve Holden's push to get the python-dev team equipped via a
> connection with the Microsoft Open Source Technology Center. The OSTC
> team provides Micr
ict on every call.
>
I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>> def f(**kwargs):
... kwargs[1] = "dummy"
... print(kwargs)
...
>>> f(this="Guido", that="Raymond", the_other="Steve")
{'this
Guido van Rossum wrote:
> On Fri, Apr 16, 2010 at 4:38 PM, Steve Holden wrote:
>> I'm sure we wouldn't want to go so far as to inhibit this. (Py 3.1)
>>
>>>>> def f(**kwargs):
>> ... kwargs[1] = "dummy"
>> ... print(kwargs)
'll be happy to change IronPython to be more compatible. :)
>
>
This would be a lose anyway, since the CPython specifications suggest
that you should not rely on being able to change locals() (or at least
shouldn't expect that such changes are actually reflected in the local
namespace)
901 - 1000 of 1536 matches
Mail list logo
