> Guido van Rossum:
>
>> Whoa! Do we really need a completely different mechanism for doing the
>> same stuff we can already do?
>
Neil Hodgson <[EMAIL PROTECTED]> writes:
>One benefit I see for the path module is that it makes it easier to
> write code that behaves correctly with unicode pa
Hi,
I'm sorry, I don't seem to have done a very good job at explaining
the situation. I'll try again:
'getch()' is a low-level function provided on Windows to capture a
single character of input from a user, /without echoing it to the
screen/. As far as I can tell there's no other way of doi
Justin wrote:
> When I used py2exe to create executable file, "cephes" module missing
> error occurred.
>
> I have installed python 2.3 and scientific and numeric python.
>
> Can anybody suggest me how to resolve the problem?
python-dev is for development *of* python, not *with* python. Please
When I used py2exe to create executable file, "cephes" module missing error occurred.
I have installed python 2.3 and scientific and numeric python.
Can anybody suggest me how to resolve the problem?
thanks,
Justin
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
___
Hi All:
I have a bundle of python script files (developed based on 2.*) in one application. Is there a way to create a single Dos executable file?
thanks,
Justin
Yahoo! Mail Mobile
Take Yahoo! Mail with you! Check email on your mobile phone.___
P
Guido van Rossum:
> Whoa! Do we really need a completely different mechanism for doing the
> same stuff we can already do?
One benefit I see for the path module is that it makes it easier to
write code that behaves correctly with unicode paths on Windows.
Currently, to implement code that may
> Raymond Hettinger wrote:
> > Use copy.copy() for generic copying -- it works across a wide range
of
> > objects. Alternatively, use the constructor as generic way to make
> > duplicates:
> >
> >dup = set(s)
> >dup = list(l)
> >dup = dict(d)
> >dup = tuple(t) # note, the dupli
Raymond Hettinger wrote:
> [Shane Holloway]
>
>>I would agree generic clearing is a lark in terms of programming
>>feature. However, I have been asked how to clear a list more than a
>>handful of times.
>
> list.clear() does not solve the root problem. The question is
> symptomatic of not unde
Raymond Hettinger wrote:
> Use copy.copy() for generic copying -- it works across a wide range of
> objects. Alternatively, use the constructor as generic way to make
> duplicates:
>
>dup = set(s)
>dup = list(l)
>dup = dict(d)
>dup = tuple(t) # note, the duplicate is original
"Resource managed"?
On 6/30/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
>
> For instance, if the new magic methods are added to decimal.Cont
"Raymond Hettinger" <[EMAIL PROTECTED]> writes:
> With 343 accepted, we can now add __enter__() and __exit__() methods to
> objects.
>
> What term should describe those objects in the documentation?
Hmm, don't know.
I talked about an object 'that conformed to the with protocol' at
EuroPython,
[Shane Holloway]
> I would agree generic clearing is a lark in terms of programming
> feature. However, I have been asked how to clear a list more than a
> handful of times.
list.clear() does not solve the root problem. The question is
symptomatic of not understanding slicing. Avoidance of tha
[Raymond Hettinger]
>> the current idiom:
>>
>>mylist[:] = [] # clear
[Fred L. Drake, Jr.]
> Unless you happen to prefer the other current idiom:
>
>del mylist[:]
Or my personal favorite,
while mylist:
del mylist[::2]
Then the original index positions with the most con
Raymond Hettinger wrote:
> I would think that that generic clearing is a lark. First, it only
> applies to mutable objects. Second, it would likely only be useful in
> the presence of a generic method for adding to the cleared container (as
> opposed to the existing append(), add(), and setitem()
On Thursday 30 June 2005 17:26, Raymond Hettinger wrote:
> the current idiom:
>
>mylist[:] = [] # clear
Unless you happen to prefer the other current idiom:
del mylist[:]
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
With 343 accepted, we can now add __enter__() and __exit__() methods to
objects.
What term should describe those objects in the documentation?
For instance, if the new magic methods are added to decimal.Context(),
do we then describe Context objects as "withable" ;-)
The PEP itself doesn't pro
[Nicolas Fleury]
> This comment reminds me another small inconsistency/annoyance.
>
> Should copy and clear functions be added to lists, to be more
consistent
> with dict and set, and easing generic code?
I think not.
Use copy.copy() for generic copying -- it works across a wide range of
objec
Michael Sparks wrote:
...
> Indeed - Greenlets allows you to build the functionality you propose without
> having to change the language.
>
>
>>>For example, with Greenlets you would use the .switch() method of a
>>
>>specific greenlet instance to switch to it, and with my python-native
>>thr
Barry Warsaw wrote:
> I've been looking at the API for sets.Set and built-in set objects in
> Python 2.4.1 and I think I have found some minor inconsistencies.
This comment reminds me another small inconsistency/annoyance.
Should copy and clear functions be added to lists, to be more consistent
> If there are no objections, I propose to do the following (only in
> Python 2.4 and 2.5):
>
> * Add set.union_update() as an alias for set.update().
No. It was intentional to drop the duplicate method with the
hard-to-use name. There was some thought given to deprecating
sets.union_upda
On Sunday 26 Jun 2005 12:04, Adam Olsen wrote:
> On 6/26/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> > Have a look at stackless python. http://www.stackless.com/
> On 6/26/05, Florian Schulze <[EMAIL PROTECTED]> wrote:
> > Also look at greenlets, they are in the py lib http://codespeak.net/py
On Thu, Jun 30, 2005, Barry Warsaw wrote:
>
> If there are no objections, I propose to do the following (only in
> Python 2.4 and 2.5):
>
> * Add set.union_update() as an alias for set.update().
> * Add to docstrings for all methods that 't' can be any iterable.
> * Update texinf
I've been looking at the API for sets.Set and built-in set objects in
Python 2.4.1 and I think I have found some minor inconsistencies.
Background: we have an object that is very similar to "sets" and we
originally modeled the API after sets.Set since we started with Python
2.3. Now I'm trying to
> Should I write a PEP?
No. Just let it evolve naturally.
The next step is for a builtin C version. That will likely happen as
soon as one of us has the time and inclination to write it.
If that works out well, then writing decimal literals like 123d may be
plausible.
And, if that works out w
Should I write a PEP?
- Fredrik
___
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
25 matches
Mail list logo
