On 24Apr2009 18:20, Toshio Kuratomi 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 else
| > tried t
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
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 tuple
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 n
On Apr 24, 2009, at 6:05 PM, Paul Moore wrote:
- Windows systems where broken Unicode (lone surrogates or whatever)
isn't involved
- Unix systems where the user's stated filesystem encoding is correct
Can you honestly say that this isn't the vast majority of real-world
environments? (IIRC, you a
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
---
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 i
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, pri
2009/4/24 Stephen J. Turnbull :
> 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 c
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
un
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 encod
2009/4/24 Eric Smith :
>> 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 code to gen
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 in
Mark Dickinson wrote:
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy 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 h
On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy 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 shown an interest
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
_
> 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
Pytho
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 ex
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 xemacs.org> writes:
> >
> > Well, the problem is that both parts are false. If you didn't start
> > with a valid string in a known enco
2009/4/22 "Martin v. Löwis" :
> 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 Python codecs.
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
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
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
> 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 decorate/sort/un
Antoine Pitrou writes:
> Stephen J. Turnbull 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
> >
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
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 even:
Raymond Hettinger 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, value in
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 the
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
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 quite
Stephen J. Turnbull 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.
Which
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'v
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 di
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 fr
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 Y2
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 k
2009/4/24 Antoine Pitrou :
> Aahz 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
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
Average
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 n
Aahz 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 to
On Fri, Apr 24, 2009, Paul Moore wrote:
> 2009/4/24 Simon Cross :
>>
>> 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
> fundamental problem
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 *pr
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. Topi
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:
http://mail.pytho
2009/4/24 Simon Cross :
> On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman 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 encodin
On Fri, Apr 24, 2009 at 12:04 PM, Glenn Linderman 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.
> (Cheek to
On Fri, Apr 24, 2009 at 11:22 AM, Glenn Linderman 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 py3,
> where things th
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" 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
charact
On Wed, Apr 22, 2009 at 8:50 AM, "Martin v. Löwis" 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 accurately. Unfortunate
50 matches
Mail list logo
