Advanced Python Training at PyCon PL
You have intermediate Python skills and would like learn more about:
* Comprehensions
* Decorators
* Context managers
* Descriptors
* Metaclasses and
* Patterns?
Than you should attend this two-day training that provides
Chris Angelico ros...@gmail.com writes:
Generally, I'm working with pure ASCII, but port those same algorithms
to Python and you'll easily be able to read in a file in some known
encoding and manipulate it as Unicode.
If it's pure ASCII, you can use the bytes or bytearray type.
It's not so
On Tuesday, July 17, 2012 12:39:53 PM UTC-7, Mark Lawrence wrote:
I would like to spend more time on this thread, but unfortunately the 44
ton artic carrying Java in a Nutshell Volume 1 Part 1 Chapter 1
Paragraph 1 Sentence 1 has just arrived outside my abode and needs
unloading :-)
That
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.
On Sat, 18 Aug 2012 11:26:21 -0700, Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes:
(There is an extension to UCS-2,
On Sat, 18 Aug 2012 11:30:19 -0700, wxjmfauth wrote:
I'm aware of this (and all the blah blah blah you are explaining).
This always the same song. Memory.
Exactly. The reason it is always the same song is because it is an
important song.
No offense here. But this is an *american*
On Sat, 18 Aug 2012 09:51:37 -0600, Ian Kelly wrote about PEP 393:
The change does not just benefit ASCII users. It primarily benefits
anybody using a wide unicode build with strings mostly containing only
BMP characters.
Just to be clear:
If you have many strings which are *mostly* BMP,
On Sat, 18 Aug 2012 11:05:07 -0700, wxjmfauth wrote:
As I understand (I think) the undelying mechanism, I can only say, it is
not a surprise that it happens.
Imagine an editor, I type an a, internally the text is saved as ascii,
then I type en é, the text can only be saved in at least
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 this myth that PEP 393 uses Latin-1
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 this myth that
On Sun, Aug 19, 2012 at 5:15 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
--
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 steve+comp.lang.pyt...@pearwood.info 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
On Sun, Aug 19, 2012 at 6:11 PM, Paul Rubin no.email@nospam.invalid wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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.
Chris Angelico ros...@gmail.com 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?
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 steve+comp.lang.pyt...@pearwood.info wrote:
SNIP.
Even with a break, why bother continuing through the body of the
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
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 3.3.0a4+
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.
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
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 ASCII strings.
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 and
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
lipskathe...@yahoo.co.uk 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
--
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.
On Sun, Aug 19, 2012 at 8:19 PM, wxjmfa...@gmail.com 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
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
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 and
On 19/08/12 11:19, Chris Angelico wrote:
On Sun, Aug 19, 2012 at 8:13 PM, lipska the kat
lipskathe...@yahoo.co.uk 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
On Sun, 19 Aug 2012 01:11:56 -0700, Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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.
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 steve+comp.lang.pyt...@pearwood.info wrote:
[snip]
that functions must only
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 steve+comp.lang.pyt...@pearwood.info
Le dimanche 19 août 2012 12:26:44 UTC+2, Chris Angelico a écrit :
On Sun, Aug 19, 2012 at 8:19 PM, wxjmfa...@gmail.com 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,
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, wxjmfa...@gmail.com wrote:
This is precicely the weak point of this flexible
representation. It uses latin-1 and latin-1 is for
most users
(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 :
SNIP
No, it uses Unicode, and as an optimization, attempts to store the
codepoints in less than four bytes
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
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, wxjmfa...@gmail.com wrote:
This is precicely the weak point of
On Sun, 19 Aug 2012 01:04:25 -0700, Paul Rubin wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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.
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
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, wxjmfa...@gmail.com
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 UTC+2, Chris
On 19 August 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.
Do the problems have a significant impact on any real application
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.
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
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 my Windows
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
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
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, wxjmfa...@gmail.com 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%
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:
On 08/19/2012 12:25 PM, crispy wrote:
SNIP
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
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
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 1000% slowdown
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
Terry Reedy tjre...@udel.edu 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
On Sun, Aug 19, 2012 at 12:33 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
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
--
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
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:
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
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, please report
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
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 - my
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 application,
Ian Kelly ian.g.ke...@gmail.com 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.
--
On Sun, Aug 19, 2012 at 12:20 PM, Paul Rubin no.email@nospam.invalid wrote:
Ian Kelly ian.g.ke...@gmail.com 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
On Sun, Aug 19, 2012 at 11:50 AM, Ian Kelly ian.g.ke...@gmail.com 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
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 ian.g.ke...@gmail.com writes:
print (type(bytes(range(256)).decode('latin1')))
class 'str'
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:
SNIP
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,
On Sun, 19 Aug 2012 10:48:06 -0700, Paul Rubin wrote:
Terry Reedy tjre...@udel.edu 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.
On Sun, 19 Aug 2012 11:50:12 -0600, Ian Kelly wrote:
On Sun, Aug 19, 2012 at 12:33 AM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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,
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:
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!
--
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…' *
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 know why
In article k0rj38$2gc$1...@reader1.panix.com, kj no.em...@please.post
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
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
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
On Mon, Aug 20, 2012 at 4:09 AM, Mark Lawrence breamore...@yahoo.co.uk 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
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 eta last command, line 1, in module
On Saturday, 18 August 2012 00:42:00 UTC+5:30, Ian wrote:
On Fri, Aug 17, 2012 at 6:46 AM, coldfire amangill.coldf...@gmail.com 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
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 tjre...@udel.edu 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
In article mailman.3531.1345416176.4697.python-l...@python.org,
Chris Angelico ros...@gmail.com 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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
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 needs:
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 1000%
On 8/19/2012 6:42 PM, Chris Angelico wrote:
On Mon, Aug 20, 2012 at 3:34 AM, Terry Reedy tjre...@udel.edu 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
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.
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 this is?
On Sun, Aug 19, 2012 at 6:27 PM, coldfire amangill.coldf...@gmail.com 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
In roy-ca6d77.17031119082...@news.panix.com Roy Smith r...@panix.com writes:
In article k0rj38$2gc$1...@reader1.panix.com, kj no.em...@please.post
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,
On Sun, Aug 19, 2012 at 9:57 PM, kj no.em...@please.post 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
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
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
1 - 100 of 197 matches
Mail list logo
