On Sat, 18 Aug 2012 19:59:32 +0100, MRAB wrote:
> The problem with strings containing surrogate pairs is that you could
> inadvertently slice the string in the middle of the surrogate pair.
That's the *least* of the problems with surrogate pairs. That would be
easy to fix: check the point of the
On Sat, 18 Aug 2012 10:27:10 -0700, rusi wrote:
> For example, my sister recently saw some of my mails and was mystified
> that I had sent back 'blank mails' until I explained and pointed out
> that my answers were interleaved into what was originally sent!
No offence to your sister, who I'm sure
Steven D'Aprano wrote:
> On Sat, 18 Aug 2012 19:34:50 +0100, MRAB wrote:
>
>> "a" will be stored as 1 byte/codepoint.
>>
>> Adding "é", it will still be stored as 1 byte/codepoint.
>
> Wrong. It will be 2 bytes, just like it already is in Python 3.2.
>
> I don't know where people are getting t
On Sun, Aug 19, 2012 at 5:15 PM, Steven D'Aprano
wrote:
> The software equivalent of somebody handing you a "blank" piece of paper
> and turning it around to see if maybe there's something on the back.
Straight out of a Goon Show, that is. Heh.
ChrisA
--
http://mail.python.org/mailman/listinfo/
On Sat, 18 Aug 2012 19:35:44 -0700, Paul Rubin wrote:
> Scanning 4 characters (or a few dozen, say) to peel off a token in
> parsing a UTF-8 string is no big deal. It gets more expensive if you
> want to index far more deeply into the string. I'm asking how often
> that is done in real code.
It
Steven D'Aprano writes:
> This is a long post. If you don't feel like reading an essay, skip to the
> very bottom and read my last few paragraphs, starting with "To recap".
I'm very flattered that you took the trouble to write that excellent
exposition of different Unicode encodings in response
Steven D'Aprano writes:
> result = text[end:]
if end not near the end of the original string, then this is O(N)
even with fixed-width representation, because of the char copying.
if it is near the end, by knowing where the string data area
ends, I think it should be possible to scan backward
On Sun, Aug 19, 2012 at 6:11 PM, Paul Rubin wrote:
> Steven D'Aprano writes:
>> result = text[end:]
>
> if end not near the end of the original string, then this is O(N)
> even with fixed-width representation, because of the char copying.
>
> if it is near the end, by knowing where the string
Chris Angelico writes:
> And of course, taking the *entire* rest of the string isn't the only
> thing you do. What if you want to take the next six characters after
> that index? That would be constant time with a fixed-width storage
> format.
How often is this an issue in practice?
I wonder how
On 19/08/2012 06:21, Robert Miles wrote:
On 7/23/2012 11:18 AM, Albert van der Horst wrote:
In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
Even with a break, why bother continuing through the body of the
function
when you already have the result? When
About the exemples contested by Steven:
eg: timeit.timeit("('ab…' * 10).replace('…', 'œ…')")
And it is good enough to show the problem. Period. The
rest (you have to do this, you should not do this, why
are you using these characters - amazing and stupid
question -) does not count.
The real pro
On Sun, 19 Aug 2012 09:43:13 +0200, Peter Otten wrote:
> Steven D'Aprano wrote:
>> I don't know where people are getting this myth that PEP 393 uses
>> Latin-1 internally, it does not. Read the PEP, it explicitly states
>> that 1-byte formats are only used for ASCII strings.
>
> From
>
> Python
Hello everybody,
I would like to solve a Mixed Integer Optimization Problem with the
Branch-And-Bound Algorithm.
I designed my Minimizing function and the constraints. I tested them in a small
program in AIMMS. So I already know that they are solvable.
Now I want to solve them using Python.
I
Le dimanche 19 août 2012 10:56:36 UTC+2, Steven D'Aprano a écrit :
>
> internal implementation, and strings which fit exactly in Latin-1 will
>
And this is the crucial point. latin-1 is an obsolete and non usable
coding scheme (esp. for european languages).
We fall on the point I mentionned ab
Steven D'Aprano wrote:
> On Sun, 19 Aug 2012 09:43:13 +0200, Peter Otten wrote:
>
>> Steven D'Aprano wrote:
>
>>> I don't know where people are getting this myth that PEP 393 uses
>>> Latin-1 internally, it does not. Read the PEP, it explicitly states
>>> that 1-byte formats are only used for AS
On Sun, 19 Aug 2012 02:04:20 -0700, Rebekka-Marie wrote:
> I would like to solve a Mixed Integer Optimization Problem with the
> Branch-And-Bound Algorithm.
[...]
> Is there a module / methods that I can download or a ready-made program
> text that you know about, where I can put my constraints an
On 19/08/12 07:09, Steven D'Aprano wrote:
This is a long post. If you don't feel like reading an essay, skip to the
very bottom and read my last few paragraphs, starting with "To recap".
Thank you for this excellent post,
it has certainly cleared up a few things for me
[snip]
incidentally
>
On Sun, Aug 19, 2012 at 8:13 PM, lipska the kat
wrote:
> The date stamp is different but the Python version is the same
Check out what 'sys.maxunicode' is in each of those Pythons. It's
possible that one is a wide build and the other narrow.
ChrisA
--
http://mail.python.org/mailman/listinfo/pyt
Le dimanche 19 août 2012 11:37:09 UTC+2, Peter Otten a écrit :
You know, the techincal aspect is one thing. Understanding
the coding of the characters as a whole is something
else. The important point is not the coding per se, the
relevant point is the set of characters a coding may
represent.
Y
On Sun, Aug 19, 2012 at 8:19 PM, wrote:
> This is precicely the weak point of this flexible
> representation. It uses latin-1 and latin-1 is for
> most users simply unusable.
No, it uses Unicode, and as an optimization, attempts to store the
codepoints in less than four bytes for most strings. T
On 19/08/2012 11:04, Steven D'Aprano wrote:
On Sun, 19 Aug 2012 02:04:20 -0700, Rebekka-Marie wrote:
I would like to solve a Mixed Integer Optimization Problem with the
Branch-And-Bound Algorithm.
[...]
Is there a module / methods that I can download or a ready-made program
text that you know
On 19/08/2012 09:54, wxjmfa...@gmail.com wrote:
About the exemples contested by Steven:
eg: timeit.timeit("('ab…' * 10).replace('…', 'œ…')")
And it is good enough to show the problem. Period. The
rest (you have to do this, you should not do this, why
are you using these characters - amazing an
On 19/08/12 11:19, Chris Angelico wrote:
On Sun, Aug 19, 2012 at 8:13 PM, lipska the kat
wrote:
The date stamp is different but the Python version is the same
Check out what 'sys.maxunicode' is in each of those Pythons. It's
possible that one is a wide build and the other narrow.
Ah ...
I
On Sun, 19 Aug 2012 01:11:56 -0700, Paul Rubin wrote:
> Steven D'Aprano writes:
>> result = text[end:]
>
> if end not near the end of the original string, then this is O(N) even
> with fixed-width representation, because of the char copying.
Technically, yes. But it's a straight copy of a c
On 19/08/12 09:55, Mark Lawrence wrote:
On 19/08/2012 06:21, Robert Miles wrote:
On 7/23/2012 11:18 AM, Albert van der Horst wrote:
In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
[snip]
that functions must only have one exit?
[snip[
Surely the
On 19/08/2012 12:50, lipska the kat wrote:
On 19/08/12 09:55, Mark Lawrence wrote:
On 19/08/2012 06:21, Robert Miles wrote:
On 7/23/2012 11:18 AM, Albert van der Horst wrote:
In article <5006b48a$0$29978$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
[snip]
that functions mus
Le dimanche 19 août 2012 12:26:44 UTC+2, Chris Angelico a écrit :
> On Sun, Aug 19, 2012 at 8:19 PM, wrote:
>
> > This is precicely the weak point of this flexible
>
> > representation. It uses latin-1 and latin-1 is for
>
> > most users simply unusable.
>
>
>
> No, it uses Unicode, and as
On 08/19/2012 08:14 AM, wxjmfa...@gmail.com wrote:
> Le dimanche 19 août 2012 12:26:44 UTC+2, Chris Angelico a écrit :
>> On Sun, Aug 19, 2012 at 8:19 PM, wrote:
>>
>>> This is precicely the weak point of this flexible
>>> representation. It uses latin-1 and latin-1 is for
>>> most users simply u
(pardon the resend, but I accidentally omitted a couple of words)
On 08/19/2012 08:14 AM, wxjmfa...@gmail.com wrote:
> Le dimanche 19 août 2012 12:26:44 UTC+2, Chris Angelico a écrit :
>>
>>
>>
>> No, it uses Unicode, and as an optimization, attempts to store the
>> codepoints in less than four by
Hi Steve,
> I don't think I'm some sort of hyper-evolved mega-genius with a brain the
> size of a planet, I'm just some guy.
Based on reading thousands of your posts over the past 4 years, I'll
have to respectfully disagree with you on your assertion that you are
not some hyper-evolved genius wi
Le dimanche 19 août 2012 14:29:17 UTC+2, Dave Angel a écrit :
> On 08/19/2012 08:14 AM, wxjmfa...@gmail.com wrote:
>
> > Le dimanche 19 ao�t 2012 12:26:44 UTC+2, Chris Angelico a �crit :
>
> >> On Sun, Aug 19, 2012 at 8:19 PM, wrote:
>
> >>
>
> >>> This is precicely the weak point of this
On Sun, 19 Aug 2012 01:04:25 -0700, Paul Rubin wrote:
> Steven D'Aprano writes:
>> This standard data structure is called UCS-2 ... There's an extension
>> to UCS-2 called UTF-16
>
> My own understanding is UCS-2 simply shouldn't be used any more.
Pretty much. But UTF-16 with lax support for
On Sun, 19 Aug 2012 03:19:23 -0700, wxjmfauth wrote:
> This is precicely the weak point of this flexible representation. It
> uses latin-1 and latin-1 is for most users simply unusable.
That's very funny.
Are you aware that your post is entirely Latin-1?
> Fascinating, isn't it? Devs are devel
On 19/08/2012 13:59, wxjmfa...@gmail.com wrote:
Le dimanche 19 août 2012 14:29:17 UTC+2, Dave Angel a écrit :
On 08/19/2012 08:14 AM, wxjmfa...@gmail.com wrote:
Le dimanche 19 ao�t 2012 12:26:44 UTC+2, Chris Angelico a �crit :
On Sun, Aug 19, 2012 at 8:19 PM, wrote:
This is pre
Le dimanche 19 août 2012 15:46:34 UTC+2, Mark Lawrence a écrit :
> On 19/08/2012 13:59, wxjmfa...@gmail.com wrote:
>
> > Le dimanche 19 ao�t 2012 14:29:17 UTC+2, Dave Angel a �crit :
>
> >> On 08/19/2012 08:14 AM, wxjmfa...@gmail.com wrote:
>
> >>
>
> >>> Le dimanche 19 ao�t 2012 12:26:44
On 19 August 2012 15:09, wrote:
> I can not give you more numbers than those I gave.
> As a end user, I noticed and experimented my random tests
> are always slower in Py3.3 than in Py3.2 on my Windows platform.
>
Do the problems have a significant impact on any real application (rather
than ran
On 19/08/2012 15:09, wxjmfa...@gmail.com wrote:
I can not give you more numbers than those I gave.
As a end user, I noticed and experimented my random tests
are always slower in Py3.3 than in Py3.2 on my Windows platform.
Once again you refuse to supply anything to back up what you say.
It
On 19/08/12 15:25, Steven D'Aprano wrote:
Not necessarily. Presumably you're scanning each page into a single
string. Then only the pages containing a supplementary plane char will be
bloated, which is likely to be rare. Especially since I don't expect your
OCR application would recognise many n
Le dimanche 19 août 2012 16:48:48 UTC+2, Mark Lawrence a écrit :
> On 19/08/2012 15:09, wxjmfa...@gmail.com wrote:
>
>
>
> >
>
> > I can not give you more numbers than those I gave.
>
> > As a end user, I noticed and experimented my random tests
>
> > are always slower in Py3.3 than in Py3.2
On 8/19/2012 4:54 AM, wxjmfa...@gmail.com wrote:
About the exemples contested by Steven:
eg: timeit.timeit("('ab…' * 10).replace('…', 'œ…')")
And it is good enough to show the problem. Period.
Repeating a false claim over and over does not make it true. Two people
on pydev claim that 3.3 is *f
I have an example:
def pairwiseScore(seqA, seqB):
prev = -1
score = 0
length = len(seqA)
similarity = []
relative_similarity = []
for x in xrange(length):
if seqA[x] == seqB[x]:
if (x
Here's first code -> http://codepad.org/RcKTTiYa
And here's second -> http://codepad.org/zwEQKKeV
--
http://mail.python.org/mailman/listinfo/python-list
On Aug 19, 2012 5:22 PM, wrote
>
> Py 3.2.3
> >>> timeit.timeit("('aœ€'*100).replace('a', 'œ€é')")
> 4.99396356635981
>
> Py 3.3b2
> >>> timeit.timeit("('aœ€'*100).replace('a', 'œ€é')")
> 7.560455708007855
>
> Maybe, not so demonstative. It shows at least, we
> are far away from the 10-30% "annouc
"Steven D'Aprano" wrote in message
news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote:
[...]
If you can consistently replicate a 100% to 1000% slowdown in string
handling, please report it as a performance bug:
http://bugs.python.or
On 08/19/2012 12:25 PM, crispy wrote:
>
> So I have guessed, that characters processed by .rjust() function, are placed
> in output, relative to previous ones - NOT to first, most to left placed,
> character.
rjust() does not print to the console, it just produces a string. So if
you want to k
On 8/19/2012 4:04 AM, Paul Rubin wrote:
Meanwhile, an example of the 393 approach failing:
I am completely baffled by this, as this example is one where the 393
approach potentially wins.
I was involved in a
project that dealt with terabytes of OCR data of mostly English text.
So the char
Le dimanche 19 août 2012 19:03:34 UTC+2, Blind Anagram a écrit :
> "Steven D'Aprano" wrote in message
>
> news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
>
>
>
> On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote:
>
>
>
> [...]
>
> If you can consistently replicate a 100% to
On 8/19/2012 10:09 AM, wxjmfa...@gmail.com wrote:
I can not give you more numbers than those I gave.
As a end user, I noticed and experimented my random tests
are always slower in Py3.3 than in Py3.2 on my Windows platform.
And I gave other examples where 3.3 is *faster* on my Windows, which y
Terry Reedy writes:
>> Meanwhile, an example of the 393 approach failing:
> I am completely baffled by this, as this example is one where the 393
> approach potentially wins.
What? The 393 approach is supposed to avoid memory bloat and that
does the opposite.
>> I was involved in a project that
On Sun, Aug 19, 2012 at 12:33 AM, Steven D'Aprano
wrote:
> On Sat, 18 Aug 2012 09:51:37 -0600, Ian Kelly wrote about PEP 393:
>> There is some additional benefit for Latin-1 users, but this has nothing
>> to do with Python. If Python is going to have the option of a 1-byte
>> representation (and
Just for the story.
Five minutes after a closed my interactive interpreters windows,
the day I tested this stuff. I though:
"Too bad I did not noted the extremely bad cases I found, I'm pretty
sure, this problem will arrive on the table".
jmf
--
http://mail.python.org/mailman/listinfo/python-li
On 8/19/2012 8:59 AM, wxjmfa...@gmail.com wrote:
In August 2012, after 20 years of development, Python is not able to
display a piece of text correctly on a Windows console (eg cp65001).
cp65001 is known to not work right. It has been very frustrating. Bug
Microsoft about it, and indeed their
wrote in message
news:5dfd1779-9442-4858-9161-8f1a06d56...@googlegroups.com...
Le dimanche 19 août 2012 19:03:34 UTC+2, Blind Anagram a écrit :
"Steven D'Aprano" wrote in message
news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote
On 14.08.2012 21:22, Christian Heimes wrote:
Hello fellow Pythonistas,
Performance
===
smc.freeimage with libjpeg-turbo read JPEGs about three to six times
faster than PIL and writes JPEGs more than five times faster.
[]
Python 2.7.3
read / write cycles: 300
test image: 1210x17
On 8/19/2012 5:04 AM, Rebekka-Marie wrote:
Hello everybody,
I would like to solve a Mixed Integer Optimization Problem with the
Branch-And-Bound Algorithm.
I designed my Minimizing function and the constraints. I tested them
in a small program in AIMMS. So I already know that they are
solvable.
On 08/19/2012 01:03 PM, Blind Anagram wrote:
> "Steven D'Aprano" wrote in message
> news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
>
> On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote:
>
> [...]
> If you can consistently replicate a 100% to 1000% slowdown in string
> handling, plea
On 19/08/2012 18:51, wxjmfa...@gmail.com wrote:
Just for the story.
Five minutes after a closed my interactive interpreters windows,
the day I tested this stuff. I though:
"Too bad I did not noted the extremely bad cases I found, I'm pretty
sure, this problem will arrive on the table".
jmf
H
"Dave Angel" wrote in message
news:mailman.3519.1345399574.4697.python-l...@python.org...
[...]
This is an average slowdown by a factor of close to 2.3 on 3.3 when
compared with 3.2.
Using your measurement numbers, I get an average of 1.95, not 2.3
Yes - you are right - m
Le dimanche 19 août 2012 19:48:06 UTC+2, Paul Rubin a écrit :
>
>
> But they are not ascii pages, they are (as stated) MOSTLY ascii.
>
> E.g. the characters are 99% ascii but 1% non-ascii, so 393 chooses
>
> a much more memory-expensive encoding than UTF-8.
>
>
Imagine an us banking applicat
Ian Kelly writes:
sys.getsizeof(bytes(range(256)).decode('latin1'))
> 329
Please try:
print (type(bytes(range(256)).decode('latin1')))
to make sure that what comes back is actually a unicode string rather
than a byte string.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, Aug 19, 2012 at 12:20 PM, Paul Rubin wrote:
> Ian Kelly writes:
> sys.getsizeof(bytes(range(256)).decode('latin1'))
>> 329
>
> Please try:
>
>print (type(bytes(range(256)).decode('latin1')))
>
> to make sure that what comes back is actually a unicode string rather
> than a byte st
On Sun, Aug 19, 2012 at 11:50 AM, Ian Kelly wrote:
> Note that this only describes the structure of "compact" string
> objects, which I have to admit I do not fully understand from the PEP.
> The wording suggests that it only uses the PyASCIIObject structure,
> not the derived structures. It the
On 19/08/2012 19:11, wxjmfa...@gmail.com wrote:
Le dimanche 19 août 2012 19:48:06 UTC+2, Paul Rubin a écrit :
But they are not ascii pages, they are (as stated) MOSTLY ascii.
E.g. the characters are 99% ascii but 1% non-ascii, so 393 chooses
a much more memory-expensive encoding than UTF-8.
Ian Kelly writes:
print (type(bytes(range(256)).decode('latin1')))
>
Thanks.
--
http://mail.python.org/mailman/listinfo/python-list
W dniu niedziela, 19 sierpnia 2012 19:31:30 UTC+2 użytkownik Dave Angel napisał:
> On 08/19/2012 12:25 PM, crispy wrote:
>
> >
>
> > So I have guessed, that characters processed by .rjust() function, are
> > placed in output, relative to previous ones - NOT to first, most to left
> > placed, c
On Sun, 19 Aug 2012 10:48:06 -0700, Paul Rubin wrote:
> Terry Reedy writes:
>> I would call it O(k), where k is a selectable constant. Slowing access
>> by a factor of 100 is hardly acceptable to me.
>
> If k is constant then O(k) is the same as O(1). That is how O notation
> works.
You might
On Sun, 19 Aug 2012 11:50:12 -0600, Ian Kelly wrote:
> On Sun, Aug 19, 2012 at 12:33 AM, Steven D'Aprano
> wrote:
[...]
>> The PEP explicitly states that it only uses a 1-byte format for ASCII
>> strings, not Latin-1:
>
> I think you misunderstand the PEP then, because that is empirically
> fals
On Sun, 19 Aug 2012 18:03:34 +0100, Blind Anagram wrote:
> "Steven D'Aprano" wrote in message
> news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
>
> > If you can consistently replicate a 100% to 1000% slowdown in string
> > handling, please report it as a performance bug:
> >
> > htt
As far as I've been able to determine, Python does not remember
(immutably, that is) the working directory at the program's start-up,
or, if it does, it does not officially expose this information.
Does anyone know why this is? Is there a PEP stating the rationale
for it?
Thanks!
--
http://ma
On 8/19/2012 1:03 PM, Blind Anagram wrote:
Running Python from a Windows command prompt, I got the following on
Python 3.2.3 and 3.3 beta 2:
python33\python" -m timeit "('abc' * 1000).replace('c', 'de')"
1 loops, best of 3: 39.3 usec per loop
python33\python" -m timeit "('ab…' * 1000).repl
Il giorno domenica 19 agosto 2012 22:42:16 UTC+2, kj ha scritto:
> As far as I've been able to determine, Python does not remember
>
> (immutably, that is) the working directory at the program's start-up,
>
> or, if it does, it does not officially expose this information.
>
>
>
> Does anyone k
In article , kj
wrote:
> As far as I've been able to determine, Python does not remember
> (immutably, that is) the working directory at the program's start-up,
> or, if it does, it does not officially expose this information.
Why would you expect that it would? What would it (or you) do with
On 19/08/2012 21:42, kj wrote:
As far as I've been able to determine, Python does not remember
(immutably, that is) the working directory at the program's start-up,
or, if it does, it does not officially expose this information.
Does anyone know why this is? Is there a PEP stating the rationa
On 2012-08-19 22:42, kj wrote:
As far as I've been able to determine, Python does not remember
(immutably, that is) the working directory at the program's start-up,
or, if it does, it does not officially expose this information.
Does anyone know why this is? Is there a PEP stating the rational
On Mon, Aug 20, 2012 at 4:09 AM, Mark Lawrence wrote:
> On 19/08/2012 18:51, wxjmfa...@gmail.com wrote:
>>
>> Just for the story.
>>
>> Five minutes after a closed my interactive interpreters windows,
>> the day I tested this stuff. I though:
>> "Too bad I did not noted the extremely bad cases I f
On 8/19/2012 2:11 PM, wxjmfa...@gmail.com wrote:
Well, it seems some software producers know what they
are doing.
'€'.encode('cp1252')
b'\x80'
'€'.encode('mac-roman')
b'\xdb'
'€'.encode('iso-8859-1')
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'latin-1'
On Saturday, 18 August 2012 00:42:00 UTC+5:30, Ian wrote:
> On Fri, Aug 17, 2012 at 6:46 AM, coldfire wrote:
>
> > I would like to know that where can a python script be stored on-line from
> > were it keep running and can be called any time when required using
> > internet.
>
> > I have used
On Friday, 17 August 2012 18:16:08 UTC+5:30, coldfire wrote:
> I would like to know that where can a python script be stored on-line from
> were it keep running and can be called any time when required using internet.
>
> I have used mechanize module which creates a webbroswer instance to open a
On Mon, Aug 20, 2012 at 3:34 AM, Terry Reedy wrote:
> On 8/19/2012 4:04 AM, Paul Rubin wrote:
>> I realize the folks who designed and implemented PEP 393 are very smart
>> cookies and considered stuff carefully, while I'm just an internet user
>> posting an immediate impression of something I hadn
In article ,
Chris Angelico wrote:
> Really, the only viable alternative to PEP 393 is a fixed 32-bit
> representation - it's the only way that's guaranteed to provide
> equivalent semantics. The new storage format is guaranteed to take no
> more memory than that, and provide equivalent function
Steven D'Aprano writes:
> Of course *if* k is constant, O(k) is constant too, but k is not
> constant. In context we are talking about string indexing and slicing.
> There is no value of k, say, k = 2, for which you can say "People will
> sometimes ask for string[2] but never ask for string[3]"
On Sunday, 19 August 2012 01:19:59 UTC+10, kj wrote:
> What's the most reliable way for "module code" to determine the
> absolute path of the working directory at the start of execution?
Here's some very simple code that relies on the singleton nature of modules
that might be enough for your nee
On Monday, August 20, 2012 1:03:34 AM UTC+8, Blind Anagram wrote:
> "Steven D'Aprano" wrote in message
>
> news:502f8a2a$0$29978$c3e8da3$54964...@news.astraweb.com...
>
>
>
> On Sat, 18 Aug 2012 01:09:26 -0700, wxjmfauth wrote:
>
>
>
> [...]
>
> If you can consistently replicate a 100% to
On 8/19/2012 6:42 PM, Chris Angelico wrote:
On Mon, Aug 20, 2012 at 3:34 AM, Terry Reedy wrote:
Python has often copied or borrowed, with adjustments. This time it is the
first.
I should have added 'that I know of' ;-)
Maybe it wasn't consciously borrowed, but whatever innovation is done,
On Sun, 19 Aug 2012 14:01:15 -0700, Giacomo Alzetta wrote:
> You can obtain the working directory with os.getcwd().
Maybe. On Unix, it's possible that the current directory no longer
has a pathname. As with files, directories can be "deleted" (i.e.
unlinked) even while they're still in use.
Simi
On Monday, August 20, 2012 4:42:16 AM UTC+8, kj wrote:
> As far as I've been able to determine, Python does not remember
>
> (immutably, that is) the working directory at the program's start-up,
>
> or, if it does, it does not officially expose this information.
>
>
>
> Does anyone know why th
On Sun, Aug 19, 2012 at 6:27 PM, coldfire wrote:
> Also I have no idea how to deploy a python script online.
> I have done that on my local PC using Apache server and cgi but it Works fine.
> Whats this all called? as far as I have searched its Web Framework but I dont
> wont to develop a websit
In Roy Smith writes:
>In article , kj
>wrote:
>> As far as I've been able to determine, Python does not remember
>> (immutably, that is) the working directory at the program's start-up,
>> or, if it does, it does not officially expose this information.
>Why would you expect that it would? W
On Sun, Aug 19, 2012 at 9:57 PM, kj wrote:
> By now I have learned to expect that 99.99% of Python programmers
> will find that there's nothing wrong with behavior like the one
> described above, that it is in fact exactly As It Should Be, because,
> you see, since Python is the epitome of perfect
Good evening,
I am considering developing an iOS application that would teach average
people how to program in Python. The app will be sold on the Apple app
store.
May I develop this app? To what extent do I need to receive permission from
the Python Software Foundation? To what extent do I need
On Monday, 20 August 2012 11:57:46 UTC+10, kj wrote:
> This means that no library code can ever count on, for example,
> being able to reliably find the path to the file that contains the
> definition of __main__. That's a weakness, IMO.
No, it's not. It's a _strength_. If you've written a libr
My apologies for any double-ups and bad formatting. The new Google Groups
interface seems to have effectively shat away decades of UX for something that
I can only guess was generated randomly.
--
http://mail.python.org/mailman/listinfo/python-list
On Monday, 20 August 2012 12:57:44 UTC+10, alex23 wrote:
> a library that requires absolute knowledge of its
> installed location in order for its internals to work
That should read: "a library that requires derivation of its installed location
from the current working directory in order" etc
-
On Mon, 20 Aug 2012 01:57:46 +, kj wrote:
> In Roy Smith
> writes:
>
>>In article , kj
>>wrote:
>
>>> As far as I've been able to determine, Python does not remember
>>> (immutably, that is) the working directory at the program's start-up,
>>> or, if it does, it does not officially expose
On Monday, 20 August 2012 13:38:03 UTC+10, Steven D'Aprano wrote:
> Not so much. More of, "yes, that's a bug, but it's not an important bug.
> If you have a patch for fixing it, we'll consider it, but if you don't,
> we've got about two thousand more important bugs and features to get
> through
On Monday, 20 August 2012 12:57:44 UTC+10, alex23 wrote:
> If you've written a library that requires absolute
> knowledge of its installed location in order for its
> internals to work, then I'm not installing your library.
That should read: "requires the ability to derive absolute knowledge of
On Mon, Aug 20, 2012 at 10:35 AM, Terry Reedy wrote:
> On 8/19/2012 6:42 PM, Chris Angelico wrote:
>> However, Python goes a bit further by making it VERY clear that this
>> is a mere optimization, and that Unicode strings and bytes strings are
>> completely different beasts. In Pike, it's possibl
On Sun, 19 Aug 2012 19:24:30 -0400, Roy Smith wrote:
> In the primordial days of computing, using 8 bits to store a character
> was a profligate waste of memory. What on earth did people need with
> TWO cases of the alphabet
That's obvious, surely? We need two cases so that we can distinguish
Your only concern from the Python world will (probably; IANAL) be around
use of trademarks owned by the PSF - see
http://www.python.org/psf/trademarks/ for more.
Mark
On 20/08/2012 12:13 PM, Matthew Zipf wrote:
Good evening,
I am considering developing an iOS application that would teach ave
In article <5031bb2f$0$29972$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> > So it may be with utf-8 someday.
>
> Only if you believe that people's ability to generate data will remain
> lower than people's ability to install more storage.
We're not talking *data*, we're talki
1 - 100 of 104 matches
Mail list logo
