On Wed, Apr 22, 2009 at 8:50 AM, Martin v. Löwis mar...@v.loewis.de wrote:
For Python 3, one proposed solution is to provide two sets of APIs: a
byte-oriented one, and a character-oriented one, where the
character-oriented one would be limited to not being able to represent
all data
On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman gl...@nevcal.com wrote:
The goal of Unicode users everywhere is to use Unicode for everything, no?
After all, all real file should have Unicode based names, and the only
proper byte sequences that should exist are UTF-8 encoding Unicode bytes.
On Fri, Apr 24, 2009 at 11:22 AM, Glenn Linderman v+pyt...@g.nevcal.com wrote:
Oh clearly it is a hack. The right solution of a Path type (and friends)
was discarded in earlier discussion, because it would impact too much
existing code. The use of bytes would be annoying in the context of
2009/4/24 Simon Cross hodgestar+python...@gmail.com:
On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman gl...@nevcal.com wrote:
The goal of Unicode users everywhere is to use Unicode for everything, no?
After all, all real file should have Unicode based names, and the only
proper byte
On approximately 4/24/2009 12:59 AM, came the following characters from
the keyboard of Simon Cross:
On Wed, Apr 22, 2009 at 8:50 AM, Martin v. Löwis mar...@v.loewis.de wrote:
For Python 3, one proposed solution is to provide two sets of APIs: a
byte-oriented one, and a character-oriented one,
Can you tell me which installer of Python I need to work with
Blender and Windows Vista Home Premium?
Thanks!
Yuma Scott___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
From:
http://mail.python.org/mailman/listinfo/python-dev
About Python-Dev
***Do not post general Python questions to this list. For help with
Python please see the Python help page.***
On this list the key Python developers discuss the future of the
language and its implementation.
On Apr 24, 2009, at 8:00 AM, Paul Moore wrote:
However, it *does* agree with the reality of Windows file systems. The
fundamental problem here is that there is a strong OS disparity - for
Windows, the OS uses Unicode, for POSIX, the OS uses bytes.
It's unfortunately the case that this isn't
On Fri, Apr 24, 2009, Paul Moore wrote:
2009/4/24 Simon Cross hodgestar+python...@gmail.com:
Humour aside :), the expectation that filenames are Unicode data
simply doesn't agree with the reality of POSIX file systems.
However, it *does* agree with the reality of Windows file systems. The
Aahz aahz at pythoncraft.com writes:
The part that I haven't seen clearly addressed so far is what happens
when disks get mounted across OSes (e.g. NFS).
Unless there's some kind of native NFS API for file access, it is hopelessly out
of scope for Python. We use whatever the C library exports
Hi,
I've recently subscribed to this list and received my first Summary of
Python tracker Issues. What I find annoying are the dates, for example:
ACTIVITY SUMMARY (04/17/09 - 04/24/09)
3 x double-digits (have we learned nothing from Y2K? :-)) with the
_middle_ ones changing fastest!
I
2009/4/24 Antoine Pitrou solip...@pitrou.net:
Aahz aahz at pythoncraft.com writes:
The part that I haven't seen clearly addressed so far is what happens
when disks get mounted across OSes (e.g. NFS).
Unless there's some kind of native NFS API for file access, it is hopelessly
out
of scope
ACTIVITY SUMMARY (04/17/09 - 04/24/09)
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.
2227 open (+32) / 15427 closed (+17) / 17654 total (+49)
Open issues with patches: 865
James Y Knight writes:
It's unfortunately the case that this isn't *precisely* true. Windows
uses arbitrary 16-bit sequences, just as unix uses arbitrary 8-bit
sequences.
Including U+FFFE and U+ not a character nowhere nohow? Just
when I was thinking Microsoft would actually nail
2009-04-24 18:29:29 MRAB napisał(a):
Hi,
I've recently subscribed to this list and received my first Summary of
Python tracker Issues. What I find annoying are the dates, for example:
ACTIVITY SUMMARY (04/17/09 - 04/24/09)
3 x double-digits (have we learned nothing from Y2K? :-))
On Fri, Apr 24, 2009 at 05:29:29PM +0100, MRAB wrote:
I've recently subscribed to this list and received my first Summary of
Python tracker Issues. What I find annoying are the dates, for example:
ACTIVITY SUMMARY (04/17/09 - 04/24/09)
3 x double-digits (have we learned nothing from Y2K?
Paul Moore writes:
The pros for Martin's proposal are a uniform cross-platform interface,
and a user-friendly API for the common case.
A more accurate phrasing would be ... a user-friendly API for those
who feel very lucky today. Which is the common case, of course, but
spins a little
Followups directed to Tracker-Discuss, where the people who can do
something about it are hanging out. (They're here too, but I'm pretty
sure they'd rather discuss this issue on that list.)
Arfrever Frehtes Taifersar Arahesis writes:
2009-04-24 18:29:29 MRAB napisał(a):
Hi,
I've
Stephen J. Turnbull stephen at xemacs.org writes:
Well, the problem is that both parts are false. If you didn't start
with a valid string in a known encoding, you shouldn't treat it as
characters because it's not. Hand it to a careful API, and you'll get
an Exception raised in your face.
Is there a reason that the PyEval_CallFunction() and
PyEval_CallMethod() convenience functions remain undocumented? (i.e.,
would a doc-and-test patch to correct this be rejected?)
I didn't see any mention of this coming up in python-dev before.
Also, despite its name, PyEval_CallMethod() is
http://psf.upfronthosting.co.za/roundup/meta/issue274
___
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
Does anyone have any ideas about what to do with issue 5830 and handling the
problem in a general way (not just for sched)?
The basic problem is that decorate/compare/undecorate patterns no longer work when the primary sort keys are equal and the secondary
keys are unorderable (which is now
Raymond Hettinger python at rcn.com writes:
Would it make sense to provide a default ordering whenever the types are
the same?
This doesn't work when they are not the same :-)
Instead, you could make the decorating a bit more sophisticated:
decorated = [(key, id(value), value) for key,
Would it make sense to provide a default ordering whenever the types are
the same?
This doesn't work when they are not the same :-)
_ ~
@ @
\_/
Instead, you could make the decorating a bit more sophisticated:
decorated = [(key, id(value), value) for key, value in blah(values)]
or
Raymond Hettinger wrote:
Would it make sense to provide a default ordering whenever the types are
the same?
def object.__lt__(self, other):
if type(self) == type(other):
return id(self) id(other)
raise TypeError
No. This only makes it more
Antoine Pitrou writes:
Stephen J. Turnbull stephen at xemacs.org writes:
Well, the problem is that both parts are false. If you didn't start
with a valid string in a known encoding, you shouldn't treat it as
characters because it's not. Hand it to a careful API, and you'll get
I'm wondering if there is something we can do to mitigate
the issue in a general way. It bites that the venerable technique
of tuple sorting has lost some of its mojo. This may be
an unintended consequence of eliminating default comparisons.
I would discourage use of the
Raymond Hettinger wrote:
The problem is that a basic python pattern is now broken
in a way that may not readily surface during testing.
I'm wondering if there is something we can do to mitigate
the issue in a general way. It bites that the venerable technique
of tuple sorting has lost some
Tim Lesher schrieb:
Is there a reason that the PyEval_CallFunction() and
PyEval_CallMethod() convenience functions remain undocumented? (i.e.,
would a doc-and-test patch to correct this be rejected?)
I didn't see any mention of this coming up in python-dev before.
Also, despite its name,
On Fri, Apr 24, 2009, Raymond Hettinger wrote:
I'm wondering if there is something we can do to mitigate the issue in
a general way. It bites that the venerable technique of tuple sorting
has lost some of its mojo. This may be an unintended consequence of
eliminating default comparisons.
2009/4/22 Martin v. Löwis mar...@v.loewis.de:
To convert non-decodable bytes, a new error handler python-escape is
introduced, which decodes non-decodable bytes using into a private-use
character U+F01xx, which is believed to not conflict with private-use
characters that currently exist in
On approximately 4/24/2009 11:40 AM, came the following characters from
the keyboard of Stephen J. Turnbull:
Antoine Pitrou writes:
Stephen J. Turnbull stephen at xemacs.org writes:
Well, the problem is that both parts are false. If you didn't start
with a valid string in a known
On approximately 4/24/2009 10:06 AM, came the following characters from
the keyboard of Oleg Broytmann:
On Fri, Apr 24, 2009 at 05:29:29PM +0100, MRAB wrote:
I've recently subscribed to this list and received my first Summary of
Python tracker Issues. What I find annoying are the dates, for
Why not use U+DCxx for non-UTF-8 encodings too?
I thought of that, and was tricked into believing that only U+DC8x
is a half surrogate. Now I see that you are right, and have fixed
the PEP accordingly.
Regards,
Martin
___
Python-Dev mailing list
Python tracker wrote:
[snip]
In going through this, I notice a lot of effort by Mark Dickenson and
others to get some details of numbers computation and display right in
time for 3.1. As a certain-to-be beneficiary, I want to thank all who
contributed.
Terry Jan Reedy
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy tjre...@udel.edu wrote:
In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric hadn't
Mark Dickinson wrote:
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy tjre...@udel.edu wrote:
In going through this, I notice a lot of effort by Mark Dickenson and others
Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready
Eric Smith wrote:
Assuming that Mark's and my changes in the py3k-short-float-repr branch
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its
functionality is largely being replaced by PyOS_double_to_string, which
we're introducing on our branch.
We've checked the changes
2009/4/24 Eric Smith e...@trueblade.com:
My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in
3.2.
Having heard no dissent, I'd like to go ahead and deprecate this API. What
are the mechanics of deprecating this? Just documentation, or is there
something I should do in the
Glenn Linderman wrote:
On approximately 4/24/2009 11:40 AM, came the following characters from
And so my encoding (1) doesn't alter the data stream for any valid
Windows file name, and where the naivest of users reside (2) doesn't
alter the data stream for any Posix file name that was encoded
Raymond Hettinger wrote:
Does anyone have any ideas about what to do with issue 5830 and handling
the problem in a general way (not just for sched)?
The basic problem is that decorate/compare/undecorate patterns no longer
work when the primary sort keys are equal and the secondary keys are
2009/4/24 Stephen J. Turnbull step...@xemacs.org:
Paul Moore writes:
The pros for Martin's proposal are a uniform cross-platform interface,
and a user-friendly API for the common case.
A more accurate phrasing would be ... a user-friendly API for those
who feel very lucky today. Which
I would discourage use of the decorate/sort/undecorate pattern,
and encourage use of the key= argument. Or, if you really need
to decorate into a tuple, still pass a key= argument.
The bug report was actually about the sched module which used
heapq to prioritize tuples consisting of times,
---
I have the following code:
# len(all_svs) = 10
# the I call a function with 2 list parameters
def proc_line(line,all_svs) :
# inside the function the length of the list all_svs is 1 more - 11
# I had to workaround it
for i in
On Fri, Apr 24, 2009, leo.baren...@nokia.com wrote:
I have the following code:
# len(all_svs) = 10
# the I call a function with 2 list parameters
def proc_line(line,all_svs) :
# inside the function the length of the list all_svs is 1 more - 11
# I had to workaround it
This sounds
Toshio Kuratomi wrote:
Glenn Linderman wrote:
On approximately 4/24/2009 11:40 AM, came the following characters from
And so my encoding (1) doesn't alter the data stream for any valid
Windows file name, and where the naivest of users reside (2) doesn't
alter the data stream for any Posix file
Raymond Hettinger wrote:
I would discourage use of the decorate/sort/undecorate pattern,
and encourage use of the key= argument. Or, if you really need
to decorate into a tuple, still pass a key= argument.
The bug report was actually about the sched module which used
heapq to prioritize
Terry Reedy wrote:
Is NUL \0 allowed in POSIX file names? If not, could that be used as an
escape char. If it is not legal, then custom translated strings that
escape in the wild would raise a red flag as soon as something else
tried to use them.
AFAIK NUL should be okay but I haven't
On 24Apr2009 18:20, Toshio Kuratomi a.bad...@gmail.com wrote:
| Terry Reedy wrote:
| Is NUL \0 allowed in POSIX file names? If not, could that be used as an
| escape char. If it is not legal, then custom translated strings that
| escape in the wild would raise a red flag as soon as something
49 matches
Mail list logo
