Re: [Python-Dev] Decimal floats as default (was: discussion aboutPEP239 and 240)

[Fredrik Johansson]

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

Re: [Python-Dev] Decimal floats as default (was: discussionaboutPEP239 and 240)

[Raymond Hettinger]

> 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 well too, then there would be some basis for
Py3.0 using decimal as the default float.



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

[Python-Dev] Inconsistent API for sets.Set and build-in set

[Barry Warsaw]

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 update the API so that it's consistent with
Python 2.4's built-in set object and I've noticed the following
discrepancies.

set.Set has both an .update() method and a .union_update() method.  They
appear to be completely identical, accepting either a Set object or an
arbitrary sequence.  This is the case despite the docstring difference
for these two methods and the fact that Set.update() isn't documented on
the texinfo page.

Built-in set has only .update() though but it acts just like the set.Set
methods above.  Note that of all these methods, only Set.update() is
documented to take an iterable argument.

These inconsistencies could prove a bit problematic when porting Py2.3
applications using sets.Set to Py2.4 using built-in set.  I'd like to
fix this for Python 2.4.2, and I think the changes are pretty minimal.

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 texinfo documentation to add Set.update() and
set.union_update() and explain that all can take iterables

I consider this a bug in 2.4, not a new feature, because without it, it
makes more work in porting applications.

Thoughts?

I'm willing to Just Fix It, but if someone wants to see a patch first,
I'll be happy to generate it and post it to SF.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] Inconsistent API for sets.Set and build-in set

[Aahz]

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 texinfo documentation to add Set.update() and
> set.union_update() and explain that all can take iterables
> 
> I consider this a bug in 2.4, not a new feature, because without it, it
> makes more work in porting applications.

+0  (I'm only not +1 because I don't use sets much -- I'm still mired in
Python 2.2 -- but I'm always happy to see inconsistencies resolved)

I'll guess that Raymond will probably want 2.5 to have set.union_update()
get a PendingDeprecationWarning.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

f u cn rd ths, u cn gt a gd jb n nx prgrmmng.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding Python-Native Threads

[Michael Sparks]

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
> While internally Stackless and Greenlets may (or may not) share a lot
> with my proposed python-native threads, they differ greatly in their
> intent and the resulting interface they expose.  

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
> threads you would use the global idle() function which would decide
> for itself which thread to switch to.

This is easy enough to build using greenlets today. I tried writing an
experimental version of our generator scheduling system using greenlets
rather than generators and found it to work very nicely. I'd suggest that if 
you really want this functionality (I can understand why) that you revisit 
greenlets - they probably do what you want.

Mainly replying to say "-1",

Best Regards,


Michael.
-- 
Michael Sparks, Senior R&D Engineer, Digital Media Group
[EMAIL PROTECTED], http://kamaelia.sourceforge.net/
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This e-mail may contain personal views which are not the views of the BBC.
___
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] Inconsistent API for sets.Set and build-in set

[Raymond Hettinger]

> 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_update() but that would have just caused unnecessary grief.



>   * Add to docstrings for all methods that 't' can be any
iterable.
>   * Update texinfo documentation to add Set.update() and
> set.union_update() and explain that all can take iterables

Feel free to assign a doc patch to me.



> I consider this a bug in 2.4, not a new feature, because without it,
it
> makes more work in porting applications.

Bah.  It's just one of the handful of search/replace steps:

   Set --> set
   ImmutableSet --> frozenset
   union_update --> update




> I'm willing to Just Fix It,

Please don't.  All of the differences between set and Set were
intentional improvements (i.e. the hash algorithm's are different).



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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Nicolas Fleury]

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 
  with dict and set, and easing generic code?

(Sorry if discussed before, I haven't found anything about that in the 
archives)

Regards,
Nicolas

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

Re: [Python-Dev] Adding Python-Native Threads

[Christian Tismer]

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
>>threads you would use the global idle() function which would decide
>>for itself which thread to switch to.
> 
> 
> This is easy enough to build using greenlets today. I tried writing an
> experimental version of our generator scheduling system using greenlets
> rather than generators and found it to work very nicely. I'd suggest that if 
> you really want this functionality (I can understand why) that you revisit 
> greenlets - they probably do what you want.

I'd like to add that in most production code I saw so far,
people are much more happy with explicit switching of
(green|task)lets. The wish for free-running stuff like real
threads is a typical symptom in an early project phase.
When it becomes more serious, you will love to have as much
control as possible, and leave auto-switching to the very
rare cases like some background monitoring or other stuff
which is not really involved in you control/data flow.

ciao - chris

-- 
Christian Tismer :^)   
tismerysoft GmbH : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9A :*Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 802 86 56  mobile +49 173 24 18 776  fax +49 30 80 90 57 05
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.com/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Raymond Hettinger]

[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
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 object here :-)

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() methods for
lists, sets, and dictionaries respectively).  So, for lists, stick with
the current idiom:

   mylist[:] = []   # clear



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

[Python-Dev] Terminology for PEP 343

[Raymond Hettinger]

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 provide much of a clue.  The terms "template",
"wrapper", and "block" are over-broad and do not provide a metaphor for
setup/teardown, r entry/exit, or initialization/finalization.

Whatever term is selected, it should be well thought-out and added to
the glossary.  The choice of words will likely have a great effect on
learnability and on how people think about the new tool.


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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Fred L. Drake, Jr.]

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
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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Shane Holloway (IEEE)]

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() methods for
> lists, sets, and dictionaries respectively).  So, for lists, stick with
> the current idiom:
> 
>mylist[:] = []   # clear

Pros of list.clear:
 + easy to find in documentation and help()
 + readability & clarity of intention in code
 + commonality with other mutable collections
 + easier to search on "clear()" (well, at least for me...)

Cons of list.clear:
 + Yet another method on list
 + Three ways to do the same thing.
 mylist[:] = []
 del mylist[:]
 mylist.clear()

 (Although the implementation will use one of slice operators,
so I guess that depends on how you count ;)


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.  Personally, my opinion is that having a
list.clear method would be a net win, especially since the
implementation can be implemented via __setitem__ or __delitem__.

Are there more Cons than those I have listed?
___
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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Tim Peters]

[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 consecutive trailing 1
bits survive the longest, which is important to avoid ZODB cache bugs
.
___
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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Raymond Hettinger]

[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 that knowledge
doesn't help the person at all.  Slicing is part of Python 101 and is
basic to the language.  There is a reason this subject is presented
right at the beginning of the tutorial.

By the time a person is writing apps that modify lists in-place
(clearing and rebuilding), then they need to know how lists work.  So, a
better solution is to submit a doc patch to improve the tutorial's
presentation on the subject.

IMO, there is a much stronger case for Fredrik's proposed join()
builtin.  That addresses an issue that feels warty on the first day you
learn it and still feels that way years later.


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] Terminology for PEP 343

[Michael Hudson]

"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, which seems about right -- but is hardly an adjective!

Guard?  Monitor?  Don't really like either of these.

Cheers,
mwh

-- 
   my worst nightmares involve the alarm clock only 
   ringing on mornings after I fall asleep on minutes
   ending in an even number -- from Twisted.Quotes
___
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] Terminology for PEP 343

[Brett Cannon]

"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.Context(),
> do we then describe Context objects as "withable" ;-)
> 
> The PEP itself doesn't provide much of a clue.  The terms "template",
> "wrapper", and "block" are over-broad and do not provide a metaphor for
> setup/teardown, r entry/exit, or initialization/finalization.
> 
> Whatever term is selected, it should be well thought-out and added to
> the glossary.  The choice of words will likely have a great effect on
> learnability and on how people think about the new tool.
> 
> 
> 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/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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Nicolas Fleury]

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 object here :-)

I know all this, but why then is there a copy method for sets and 
dictionaries?  What justification is valid for sets and dictionaries 
that doesn't apply to lists?

Regards,
Nicolas

___
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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Nicolas Fleury]

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 understanding slicing.  Avoidance of that knowledge
> doesn't help the person at all.  Slicing is part of Python 101 and is
> basic to the language.  There is a reason this subject is presented
> right at the beginning of the tutorial.

I tend to not agree.  I don't think it is symptomatic of "not 
understanding slicing", but instead of "not being in a slicing state of 
mind".  What I see in day-to-day is that when programmers want to clear 
a list, they are sometimes in a situation where you have some persistent 
list that need to be cleared, so the first reflex is not to think about 
slicing.  They end up in a situation where they only use slicing to 
clear the lists they use, when their problem has nothing to do with 
slicing IMHO.

But I understand that would add yet another way to clear a list, while 
the function is necessary for sets and dictionaries.

Regards,
Nicolas

___
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] List copy and clear (was Re: Inconsistent API for sets.Set and build-in set)

[Raymond Hettinger]

> 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 object here
:-)

[Nicolas Fleury]
> I know all this, but why then is there a copy method for sets and
> dictionaries?  What justification is valid for sets and dictionaries
> that doesn't apply to lists?

Several thoughts:

* maybe it's a Dutch thing;

* dict.copy() pre-dated dict(d) and (IIRC) copy.copy();

* sets and dicts don't have the [:] syntax available to them;

* the __copy__() method is new way to make things copy.copyable
  without fattening the apparent API or rewriting the copy module;

* because generic copying isn't important enough to add more 
  ways to do the same thing;

* and because Guido believes beginners tend to copy too much
  (that is one reason why copy.copy is not a builtin) and that
  the language should encourage correct behavior.


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] Adding the 'path' module (was Re: Some RFE for review)

[Neil Hodgson]

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 see unicode paths, you must
first understand that unicode paths may be an issue, then write
conditional code that uses either a string or unicode string to hold
paths whenever a new path is created.

   Neil
___
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] how to create single exe dos file

[Justin]

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.___
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] cephes module missing

[Justin]

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


___
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] cephes module missing

[Delaney, Timothy (Tim)]

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
direct your questions to  (or via the newsgroup
comp.lang.python).

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

[Python-Dev] getch() in msvcrt does not accept extended characters.

[Darryl Dixon]

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 doing this with
Python on Windows.  The Python interface to this function is in the C
code in msvcrtmodule.c, which has a (very thin) wrapper around the raw
OS system call.  Microsoft provide a way of accepting both normal ASCII
codes, and extended characters via this system call.  Currently, the
Python wrapper in msvcrtmodule.c only supports the semantics of getting
the bare ASCII codes, and not the extended characters.  I would strongly
suggest that it should support both.

So, I guess in answer to the questions raised below;

1) I can't do it in Python code without getch() (hence the original
email)

2) I would argue that in fact getch() is 'broken' in its current Python
implementation, as it doesn't support what the OS implies /should/ be
supported (and, indeed, if I input an extended character in response to
a 'getch()' call, all I get back currently is an empty string).

Finally, I've dug a little deeper, and it looks as though if (ch >
UCHAR_MAX) then it would have to call PyUnicode_FromUnicode(s, 1)
instead.

Is it worth sending in a patch to the sourceforge patch-tracker
implementing this?  Is it OK for msvcrt_getch to return Unicode when
appropriate?

Thoughts?

Hope this helps,
D


Fredrik wrote:
>Darryl Dixon wrote:
>
>> Microsoft support capturing extended characters via _getch, but it
requires making a
>> second call to getch() if one of the 'magic' returns is encountered
in the first call (0x00
>> or 0xE0).
>
>so why not do that in your python code?
>
>> The relevant chunk of code in Python that would probably need to be
>> changed to support this appears to be in msvcrtmodule.c:
>
>if you change msvcrt, you'll break all the programs that uses getch()
in
>the prescribed way...
>
> 
-- 
Darryl Dixon <[EMAIL PROTECTED]>

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

Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE for review)

[Thomas Heller]

> 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 paths on Windows.
> Currently, to implement code that may see unicode paths, you must
> first understand that unicode paths may be an issue, then write
> conditional code that uses either a string or unicode string to hold
> paths whenever a new path is created.

Indeed.  This would probably handle the cases where you have to
manipulate file paths in code.

OTOH, Python is lacking a lot when you have to handle unicode strings on
sys.path, in command line arguments, environment variables and maybe
other places.  See, for example
http://mail.python.org/pipermail/python-list/2004-December/256969.html

I had started to work on the sys.path unicode issues, but it seems a
considerable rewrite of (not only) Python/import.c is required.  But I
fear the patch http://python.org/sf/1093253 is slowly getting out of
date.

Thomas

___
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