comp.lang.python - 26 new messages in 6 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* Editor for Python - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/1d3bfdac73cdb9d2?hl=en
* Is email.parser a good replacement for formail? - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/d1d064c864756264?hl=en
* the Gravity of Python 2 - 16 messages, 7 authors
http://groups.google.com/group/comp.lang.python/t/0afb505736567141?hl=en
* Bytes indexing returns an int - 3 messages, 3 authors
http://groups.google.com/group/comp.lang.python/t/906d7333bbd1d189?hl=en
* unicode troubles and postgres - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/86d230494673282e?hl=en
* Constructive Criticism - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/45821f6b72d33dbb?hl=en

==============================================================================
TOPIC: Editor for Python
http://groups.google.com/group/comp.lang.python/t/1d3bfdac73cdb9d2?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 9 2014 7:50 am
From: Jean-Michel Pichavant


----- Original Message -----
>
> On Jan 8, 2014, at 10:53 AM, Jean-Michel Pichavant
> <jeanmichel@sequans.com> wrote:
>
> >>> -- IMPORTANT NOTICE:
> >>>
> >>
> >> too late you have sent this to a public forum
> >
> > No pb with that, the python list is the intended recipient :)
> >
> > I tried to negotiate this with my IT guys, but it looks like it's
> > now mandatory, something related to being in the USA stock market.
> Yeah, when in doubt blame the Americans.

Sorry if I hurt your feelings, have a look at http://www.sarbanes-oxley-101.com/

I don't blame anyone, would I be blaming the law, that wouldn't imply the americans anyway.

cheers,

JM

"The Sarbanes-Oxley Act of 2002, sponsored by Paul Sarbanes and Michael Oxley, represents a huge change to federal securities law. It came as a result of the corporate financial scandals involving Enron, WorldCom and Global Crossing. Effective in 2006, all publicly-traded companies are required to implement and report internal accounting controls to the SEC for compliance."


-- IMPORTANT NOTICE:

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.





==============================================================================
TOPIC: Is email.parser a good replacement for formail?
http://groups.google.com/group/comp.lang.python/t/d1d064c864756264?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Jan 9 2014 8:05 am
From: Matěj Cepl


Hi,



I have a script (https://github.com/mcepl/gg_scraper) where I need to
read possibly malformed mbox messages. I use subprocess.Popen() and
/usr/bin/formail to clean up them to be correct mbox messages (with
correct leading From line etc.). Now I try to run tests for my script on
Travis-CI, where I don't have installed formail. Actually, I learned now
that I can run apt-get install procmail in .travis.yml. But still, I
started to think whether I couldn't fix my script to be purely Pythonic.
I know that

msg = email.message_from_string(original_msg)
print(msg.as_string(unixfrom=True))

works as a poor-man's replacement for `formail -d`. Now, I would like to
know how reliable replacement it is. Does anybody have (or know about) a
corpus of poorly formatted messages which can be fixed by formail to
test upon it?

Thanks a lot for any reply,

Matěj

--
http://www.ceplovi.cz/matej/, Jabber: mcepl@ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC

Less is more or less more.
-- Y_Plentyn on #LinuxGER
(from fortunes -- I cannot resist :-)






==============================================================================
TOPIC: the Gravity of Python 2
http://groups.google.com/group/comp.lang.python/t/0afb505736567141?hl=en
==============================================================================

== 1 of 16 ==
Date: Thurs, Jan 9 2014 8:21 am
From: Roy Smith


On Thursday, January 9, 2014 9:57:57 AM UTC-5, Chris Angelico wrote:


> And months are more
> complicated still, so it's probably easiest to use strftime:
>
> >>> time.strftime("%Y%m",time.gmtime(ts))
>
> '201401'

strftime is a non-starter at far as "easy" goes. I don't know about you, but I certainly haven't memorized the table of all the format specifiers. Is month "m" or "M"? What's "%U" or "%B". Every time I use strftime, I have to go pull up the docs and read the table. Not to mention that "%z" is not available on all platforms, and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).

> So what I'm seeing here is that the direct use of a time_t will cover
> everything in an ugly way, but that a class wrapping it up could fix
> that. And fundamentally, the only problem with datetime (which, for
> the most part, is exactly that wrapper) is that it's unobvious how to
> get a simple UTC timestamp.
>
> Has the unobviousness been solved by a simple recipe? And if so,
> should that tip be added to the datetime module docs somewhere?

No, it would be solved by a built-in method. Recipes are a cop-out. If something is complicated enough to require a recipe, and used frequently enough to be worth writing that recipe up and documenting it, you might as well have gone the one additional step and made it a method.




== 2 of 16 ==
Date: Thurs, Jan 9 2014 8:30 am
From: Mark Lawrence



On 09/01/2014 16:21, Roy Smith wrote:
>
> No, it would be solved by a built-in method. Recipes are a cop-out. If something is complicated enough to require a recipe, and used frequently enough to be worth writing that recipe up and documenting it, you might as well have gone the one additional step and made it a method.
>

So all of the itertools recipes should be part of the Python module and
not in more-itertools on pypi?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence





== 3 of 16 ==
Date: Thurs, Jan 9 2014 8:41 am
From: Tim Golden


On 09/01/2014 16:30, Mark Lawrence wrote:
> On 09/01/2014 16:21, Roy Smith wrote:
>>
>> No, it would be solved by a built-in method. Recipes are a cop-out.
>> If something is complicated enough to require a recipe, and used
>> frequently enough to be worth writing that recipe up and documenting
>> it, you might as well have gone the one additional step and made it a
>> method.
>>
>
> So all of the itertools recipes should be part of the Python module and
> not in more-itertools on pypi?

To be fair, Mark, it's a matter of taste. Raymond [the author/maintainer
of itertools] prefers not to multiply the API; other developers might
legitimately make other calls. Sometimes the cut-off is more obvious;
say, when the effort to make a recipe general purpose creates an
over-engineered API. Other times it's just preference.

Does that mean that every recipe ever conceived should be stuffed into
the class or module it uses? No; but it doesn't rule out adding things
which are genuinely useful.

I think the new statistics module has hit a nice balance on its initial
release: it's a stripped down aesthetic without precluding later additions.

TJG




== 4 of 16 ==
Date: Thurs, Jan 9 2014 8:42 am
From: Nick Cash


> and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).

The format specifiers available to Python are just whatever is available to the underlying c time.h.
The manpage for strftime indicates that %s isn't part of the C standard, but part of "Olson's timezone package", which means it's not available on Windows. Your suspicion is unfortunately correct.




== 5 of 16 ==
Date: Thurs, Jan 9 2014 7:56 am
From: Ethan Furman


On 01/09/2014 06:57 AM, Chris Angelico wrote:
> On Fri, Jan 10, 2014 at 1:14 AM, Roy Smith <roy@panix.com> wrote:
>>
>
> Thanks for this collection! Now we can discuss.

[snip]

>> Datetimes are self-describing. If I have a datetime or a timedelta, I
>> know what I've got. I've written more than one bug where I assumed a
>> number somebody handed me was in seconds but it turned out to be in ms.
>> That can never happen with a timedelta. We do a lot of stuff in
>> javascript, where times are ms, so this is a common problem for us.
>
> Sure. Though that's no different from other cases where you need
> out-of-band information to understand something, as we've just been
> discussing in the threads about text handling - if you have a puddle
> of bytes, you can't decode them to text without knowing what the
> encoding is. [1] If your data's coming from JS, it won't be a
> timedelta, it'll be a number; at some point you have to turn that into
> a timedelta object, so you still have the same problem.

Yup, and you do at the boundary instead of having a float wandering through your code with an easily forgotten meta-data
type.


> So what I'm seeing here is that the direct use of a time_t will cover
> everything in an ugly way, but that a class wrapping it up could fix
> that. And fundamentally, the only problem with datetime (which, for
> the most part, is exactly that wrapper) is that it's unobvious how to
> get a simple UTC timestamp.

It has at least one other problem: bool(midnight) == False.

--
~Ethan~


> [1] Yes, I said "puddle of bytes". What would you call it? Am
> interested to hear!

I think that's a perfect name! :)




== 6 of 16 ==
Date: Thurs, Jan 9 2014 8:01 am
From: Ethan Furman


On 01/09/2014 12:42 AM, Mark Lawrence wrote:
> On 09/01/2014 01:27, Roy Smith wrote:
>>
>> Naive datetimes are what everybody uses. It's what utcnow() gives you.
>> So why make life difficult for everybody? Python 3 didn't win a convert
>> today.
>
> Yep, dates and times are easy. That's why there are 17 issues open on the bug tracker referencing tzinfo alone. Poor
> old 1100942 is high priority, was created 12/01/2005 and has missed 3.4. So if it gets into 3.5 it'll have already
> celebrated its 10th birthday. It doesn't say much for the amount of effort that we put into looking after issues.

Mark, I hope you are addressing the community at large and not the core-devs. There are only so many of us, with
limited time available.

--
~Ethan~




== 7 of 16 ==
Date: Thurs, Jan 9 2014 8:51 am
From: Piet van Oostrum


Chris Angelico <rosuav@gmail.com> writes:

> On Fri, Jan 10, 2014 at 1:06 AM, Piet van Oostrum <piet@vanoostrum.org> wrote:
>> Chris Angelico <rosuav@gmail.com> writes:
>>
>>> On Thu, Jan 9, 2014 at 2:34 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
>>>> With time zones, as with text encodings, there is a single technically
>>>> elegant solution (for text: Unicode; for time zones: twelve simple,
>>>> static zones that never change)
>>>
>>> Twelve or twenty-four? Or are you thinking we should all be an even
>>> number of hours away from UTC, which would also work?
>>
>> Even 24 doesn't take into account DST.
>
> That was the point. We can abolish codepages by using Unicode, which
> covers everything. We could abolish time messes by having every
> locality settle permanently on one timezone; Ben's theory demands that
> all timezones be some integer number of hours +/- UTC, which IMO is
> optional, but mainly it should be easy to figure out any two
> locations' difference: just subtract one's UTC offset from the
> other's. Similarly, you can calculate the difference between two times
> at the same location by simple subtraction; currently, you also have
> to consider the possibility of a DST switch (from noon to noon across
> a switch is either 23 or 25 hours).
>
> Actually, the nearest parallel to Unicode is probably "use UTC
> everywhere", which makes for a superb internal representation and
> transmission format, but bugs most human beings :)

I don't know how other countries do it, but here, when the clock goes back, it goes from 03:00 to 02:00. So I wonder how they communicate when your plane leaves at 02:30 in that night. Which 02:30? In that case using UTC may come out handy, if it would be understood. Or do the planes just stop leaving during that interval? Not that there will be many leaving during that time in general, I presume.

--
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]




== 8 of 16 ==
Date: Thurs, Jan 9 2014 8:50 am
From: Mark Lawrence



On 09/01/2014 16:42, Nick Cash wrote:
>> and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).
>
> The format specifiers available to Python are just whatever is available to the underlying c time.h.
> The manpage for strftime indicates that %s isn't part of the C standard, but part of "Olson's timezone package", which means it's not available on Windows. Your suspicion is unfortunately correct.
>

Methinks http://www.python.org/dev/peps/pep-0431/ Time zone support
improvements may be of interest here. Still at draft issue unfortunately.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence





== 9 of 16 ==
Date: Thurs, Jan 9 2014 9:07 am
From: Roy Smith


I wrote:
> Recipes are a cop-out

On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
> So all of the itertools recipes should be part of the Python module and
> not in more-itertools on pypi?

Certainly, the recipes that are documented on the official itertools page, yes.




== 10 of 16 ==
Date: Thurs, Jan 9 2014 10:18 am
From: Mark Lawrence



On 09/01/2014 16:01, Ethan Furman wrote:
> On 01/09/2014 12:42 AM, Mark Lawrence wrote:
>> On 09/01/2014 01:27, Roy Smith wrote:
>>>
>>> Naive datetimes are what everybody uses. It's what utcnow() gives you.
>>> So why make life difficult for everybody? Python 3 didn't win a convert
>>> today.
>>
>> Yep, dates and times are easy. That's why there are 17 issues open on
>> the bug tracker referencing tzinfo alone. Poor
>> old 1100942 is high priority, was created 12/01/2005 and has missed
>> 3.4. So if it gets into 3.5 it'll have already
>> celebrated its 10th birthday. It doesn't say much for the amount of
>> effort that we put into looking after issues.
>
> Mark, I hope you are addressing the community at large and not the
> core-devs. There are only so many of us, with limited time available.
>
> --
> ~Ethan~

As I'm not a core dev to whom do you think I'm referring? I'm aware
that the high horse I get on about this is so tall that you'll need an
oxygen supply to survive should you want to sit on it, but to me this is
easily the worst aspect of the Python community as a whole. If every
regular contributor to this list was to fix even one bug a week the
figures would look rather better. Still, you can no more enforce that
than you can enforce the core devs working on Python 2.8 :)

Talking of which, have we got a PEP for that yet, or are the whingers
still simply in whinging mode?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence





== 11 of 16 ==
Date: Thurs, Jan 9 2014 10:20 am
From: Mark Lawrence



On 09/01/2014 17:07, Roy Smith wrote:
> I wrote:
>> Recipes are a cop-out
>
> On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
>> So all of the itertools recipes should be part of the Python module and
>> not in more-itertools on pypi?
>
> Certainly, the recipes that are documented on the official itertools page, yes.
>

No thank you, I don't want the Python docs getting anywhere near the
size of their Java equivalents.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence





== 12 of 16 ==
Date: Thurs, Jan 9 2014 10:33 am
From: Ethan Furman


On 01/09/2014 10:18 AM, Mark Lawrence wrote:
> On 09/01/2014 16:01, Ethan Furman wrote:
>> On 01/09/2014 12:42 AM, Mark Lawrence wrote:
>>> On 09/01/2014 01:27, Roy Smith wrote:
>>>>
>>>> Naive datetimes are what everybody uses. It's what utcnow() gives you.
>>>> So why make life difficult for everybody? Python 3 didn't win a convert
>>>> today.
>>>
>>> Yep, dates and times are easy. That's why there are 17 issues open on
>>> the bug tracker referencing tzinfo alone. Poor
>>> old 1100942 is high priority, was created 12/01/2005 and has missed
>>> 3.4. So if it gets into 3.5 it'll have already
>>> celebrated its 10th birthday. It doesn't say much for the amount of
>>> effort that we put into looking after issues.
>>
>> Mark, I hope you are addressing the community at large and not the
>> core-devs. There are only so many of us, with limited time available.
>
> As I'm not a core dev to whom do you think I'm referring?

Cool, just double-checking. :)


> Still, you can no more enforce that than you can enforce the core devs
> working on Python 2.8 :)
>
> Talking of which, have we got a PEP for that yet. . .

As a matter of fact. It's called PEP 404. ;)

--
~Ethan~




== 13 of 16 ==
Date: Thurs, Jan 9 2014 10:29 am
From: Ethan Furman


On 01/09/2014 10:20 AM, Mark Lawrence wrote:
>> On Thursday, January 9, 2014 11:30:31 AM UTC-5, Mark Lawrence wrote:
>>> So all of the itertools recipes should be part of the Python module and
>>> not in more-itertools on pypi?
>>
>> Certainly, the recipes that are documented on the official itertools page, yes.
>
> No thank you, I don't want the Python docs getting anywhere near the size of their Java equivalents.

To be fair, the recipes on the itertools page are there so that minor changes can be made (flavor to taste, so to speak)
to get exactly the semantics needed by the individual programmer.

With the timezone stuff we're looking for The One Obvious Way, which should be a method, not a recipe.

--
~Ethan~




== 14 of 16 ==
Date: Thurs, Jan 9 2014 12:35 pm
From: Chris Angelico


On Fri, Jan 10, 2014 at 3:21 AM, Roy Smith <roy@panix.com> wrote:
> On Thursday, January 9, 2014 9:57:57 AM UTC-5, Chris Angelico wrote:
>> And months are more
>> complicated still, so it's probably easiest to use strftime:
>>
>> >>> time.strftime("%Y%m",time.gmtime(ts))
>>
>> '201401'
>
> strftime is a non-starter at far as "easy" goes. I don't know about you, but I certainly haven't memorized the table of all the format specifiers. Is month "m" or "M"? What's "%U" or "%B". Every time I use strftime, I have to go pull up the docs and read the table. Not to mention that "%z" is not available on all platforms, and "%s" (which is incredibly useful) is not even documented (I suspect it's also not available on all platforms).
>

Have you ever used a regular expression? Does it bother you that both
percent-formatting and str.format() have compact/cryptic
mini-languages? Why is it a problem to have a mini-language for
formatting dates? It at least follows a measure of common sense,
unlike the PHP date function. In fact, I've given end users the
ability to enter strftime strings (eg to construct a filename), and
it's worked just fine. *Non-programmers* can figure them out without
much difficulty.

ChrisA




== 15 of 16 ==
Date: Thurs, Jan 9 2014 12:43 pm
From: Chris Angelico


On Fri, Jan 10, 2014 at 3:51 AM, Piet van Oostrum <piet@vanoostrum.org> wrote:
> I don't know how other countries do it, but here, when the clock goes back, it goes from 03:00 to 02:00. So I wonder how they communicate when your plane leaves at 02:30 in that night. Which 02:30? In that case using UTC may come out handy, if it would be understood. Or do the planes just stop leaving during that interval? Not that there will be many leaving during that time in general, I presume.
>

The fundamental is that the timezone changes. Times roll from 02:00
Daylight time through 02:30 Daylight time to the instant before 03:00
Daylight time, which doesn't happen, and instead time jumps to 02:00
Standard time and starts rolling forward.

How this is adequately communicated on the plane ticket is a separate
issue, though, and as I've never actually flown during a DST
changeover, I wouldn't know. I'm sure there would be planes departing
during those two hours (neither airlines nor airports can afford to
have two, or even one, "dead" hour!), so this must have been solved
somehow. Maybe people could figure it out from the "check-in by" time?
For instance, last time I flew, the plane departed at 0240 local time
(but this was in July, so not anywhere near changeover), and check-in
opened at 2340; so if it were the "other" 0240, then check-in would
have opened at 0040 instead. Either that, or they'll tell everyone to
arrive in time for the first instance of that time, and then just make
us all wait around for an extra hour....

ChrisA




== 16 of 16 ==
Date: Thurs, Jan 9 2014 12:54 pm
From: Roy Smith


On Thursday, January 9, 2014 3:35:05 PM UTC-5, Chris Angelico wrote:
> In fact, I've given end users the ability to enter strftime strings (eg
> to construct a filename), and it's worked just fine.

I assume you realize that "../../../../../../../../../../../../../../../../etc/passwd" is a valid strftime() format specifier? :-)

But, to answer your question, no, I have nothing against small languages, per-se (and I've done plenty of regex work). But, if my goal is to print a time in some human-readable form:

>>> print t

is a lot easier than anything involving strftime().





==============================================================================
TOPIC: Bytes indexing returns an int
http://groups.google.com/group/comp.lang.python/t/906d7333bbd1d189?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 9 2014 9:05 am
From: Piet van Oostrum


Ned Batchelder <ned@nedbatchelder.com> writes:

> On 1/8/14 11:08 AM, wxjmfauth@gmail.com wrote:
>> Byte strings (encoded code points) or native unicode is one
>> thing.
>>
>> But on the other side, the problem is elsewhere. These very
>> talented ascii narrow minded, unicode illiterate devs only
>> succeded to produce this (I, really, do not wish to be rude).
>
> If you don't want to be rude, you are failing. You've been told a
> number of times that your obscure micro-benchmarks are meaningless. Now
> you've taken to calling the core devs narrow-minded and Unicode
> illiterate. They are neither of these things.
>
> Continuing to post these comments with no interest in learning is rude.
> Other recent threads have contained details rebuttals of your views,
> which you have ignored. This is rude. Please stop.

Please ignore jmf's repeated nonsense.
--
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]




== 2 of 3 ==
Date: Thurs, Jan 9 2014 9:28 am
From: Ethan Furman


On 01/09/2014 09:05 AM, Piet van Oostrum wrote:
> Ned Batchelder <ned@nedbatchelder.com> writes:
>
>> On 1/8/14 11:08 AM, wxjmfauth@gmail.com wrote:
>>> Byte strings (encoded code points) or native unicode is one
>>> thing.
>>>
>>> But on the other side, the problem is elsewhere. These very
>>> talented ascii narrow minded, unicode illiterate devs only
>>> succeded to produce this (I, really, do not wish to be rude).
>>
>> If you don't want to be rude, you are failing. You've been told a
>> number of times that your obscure micro-benchmarks are meaningless. Now
>> you've taken to calling the core devs narrow-minded and Unicode
>> illiterate. They are neither of these things.
>>
>> Continuing to post these comments with no interest in learning is rude.
>> Other recent threads have contained details rebuttals of your views,
>> which you have ignored. This is rude. Please stop.
>
> Please ignore jmf's repeated nonsense.

Or ban him. His one, minor, contribution has been completely swamped by the rest of his belligerent, unfounded, refuted
posts.

--
~Ethan~




== 3 of 3 ==
Date: Thurs, Jan 9 2014 11:36 am
From: Serhiy Storchaka


09.01.14 19:28, Ethan Furman написав(ла):
> On 01/09/2014 09:05 AM, Piet van Oostrum wrote:
>> Please ignore jmf's repeated nonsense.
>
> Or ban him. His one, minor, contribution has been completely swamped by
> the rest of his belligerent, unfounded, refuted posts.

Please not. I have a fun from every his appearance.






==============================================================================
TOPIC: unicode troubles and postgres
http://groups.google.com/group/comp.lang.python/t/86d230494673282e?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Jan 9 2014 10:49 am
From: Ethan Furman


So I'm working with postgres, and I get a datadump which I try to restore to my test system, and I get this:

ERROR: value too long for type character varying(4)
CONTEXT: COPY res_currency, line 32, column symbol: "руб"

"py6" sure looks like it should fit, but it don't. Further investigation revealed that "py6" is made up of the bytes d1
80 d1 83 d0 b1.

Any ideas on what that means, exactly?

--
~Ethan~




== 2 of 3 ==
Date: Thurs, Jan 9 2014 11:50 am
From: Peter Otten <__peter__@web.de>


Ethan Furman wrote:

> So I'm working with postgres, and I get a datadump which I try to restore
> to my test system, and I get this:
>
> ERROR: value too long for type character varying(4)
> CONTEXT: COPY res_currency, line 32, column symbol: "руб"
>
> "py6" sure looks like it should fit, but it don't. Further investigation
> revealed that "py6" is made up of the bytes d1 80 d1 83 d0 b1.
>
> Any ideas on what that means, exactly?

It may look like the ascii "py6", but you have three cyrillic letters:

>>> import unicodedata as ud
>>> [ud.name(c) for c in u"руб"]
['CYRILLIC SMALL LETTER ER', 'CYRILLIC SMALL LETTER U', 'CYRILLIC SMALL
LETTER BE']

The dump you are seeing are the corresponding bytes in UTF-8:

>>> u"руб".encode("utf-8")
'\xd1\x80\xd1\x83\xd0\xb1'

So postgres may be storing the string as utf-8.





== 3 of 3 ==
Date: Thurs, Jan 9 2014 11:51 am
From: Ethan Furman


On 01/09/2014 10:49 AM, Ethan Furman wrote:
> So I'm working with postgres, and I get a datadump which I try to restore to my test system, and I get this:
>
> ERROR: value too long for type character varying(4)
> CONTEXT: COPY res_currency, line 32, column symbol: "руб"
>
> "py6" sure looks like it should fit, but it don't. Further investigation revealed that "py6" is made up of the bytes d1
> 80 d1 83 d0 b1.
>
> Any ideas on what that means, exactly?

For the curious, it means CYRILLIC SMALL LETTER ER, CYRILLIC SMALL LETTER U, CYRILLIC CAPITAL LETTER IE WITH GRAVE in
utf-8 format.

The problem was I had created the database from template0 instead of template1, and 0 is SQL-ASCII while 1 is UTF8.

--
~Ethan~





==============================================================================
TOPIC: Constructive Criticism
http://groups.google.com/group/comp.lang.python/t/45821f6b72d33dbb?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Jan 9 2014 12:08 pm
From: jeremiah valerio


On Thursday, January 9, 2014 3:56:37 AM UTC-6, Peter Otten wrote:
> jeremiahvalerio123@gmail.com wrote:
>
>
>
> > Hi, hows it going I've been self teaching myself python, and i typed up
>
> > this small script now i know its not the best the coding is not the best
>
> > but i would like to know of ways to make a small script like this better
>
> > so all constructive critisim is Welcome.
>
> >
>
> >
>
> >
>
> > Here is the link to the code
>
> >
>
> > " http://pastebin.com/5uCFR2pz "
>
>
>
> > time.sleep(1)
>
> > import time
>
> > print("Closing in 9 ")
>
> > time.sleep(1)
>
> > import time
>
> > print("Closing in 8 ")
>
>
>
> - You should import modules just once, at the beginning of your script.
>
>
>
> - Repetetive tasks are best handled with a for-loop, e. g.:
>
>
>
> >>> import time
>
> >>> for seconds_left in reversed(range(1, 10)):
>
> ... print("Closing in", seconds_left, "seconds")
>
> ... time.sleep(1)
>
> ...
>
> Closing in 9 seconds
>
> Closing in 8 seconds
>
> Closing in 7 seconds
>
> Closing in 6 seconds
>
> Closing in 5 seconds
>
> Closing in 4 seconds
>
> Closing in 3 seconds
>
> Closing in 2 seconds
>
> Closing in 1 seconds
>
>
>
> > user_input = input("\nWhos your favorite Football team? \n 1.Arizona
>
> > Cardinals\n 2.Atlanta Falcons\n 3.Baltimore Ravens\n 4.Buffalo Bills\n
>
> > 5.Miami Dolphins\n 6.Minnesota Vikings \n 7.New England Patriots \n
>
> > 8.New Orleans Saints \n 9.Carolina
>
> [snip]
>
>
>
> Python offers triple-quoted strings which may include newline literals:
>
>
>
> user_input = input("""
>
> Who's your favorite Football team?
>
> 1. Arizona Cardinals
>
> 2. Atlanta Falcons
>
> ...
>
> """)
>
>
>
> > if user_input == "1" :
>
> > print("\nThey suck! BYE!")
>
> >
>
> > elif user_input == "2" :
>
> > print("\nThey suck! BYE!")
>
> >
>
> > elif user_input == "3" :
>
> > print("\nThey suck!BYE!")
>
> [snip]
>
>
>
> Ignoring the typos you are taking the same action for all inputs but "17".
>
> So:
>
>
>
> if user_input != "17":
>
> print()
>
> print("They suck! BYE!")
>
>
>
> You should give some thought how unexpected user input like "", "123",
>
> "whatever" should be handled.
>
>
>
> > elif user_input == "no" :
>
> > print("\nAlrighty bye have a nice day! :)\n\nClosing in 10.")
>
> > import time
>
> > time.sleep(1)
>
> > import time
>
> > print("Closing in 9 ")
>
> > time.sleep(1)
>
> > import time
>
> > print("Closing in 8 ")
>
> > time.sleep(1)
>
> > import time
>
>
>
> OK, you are doing the count-down thing twice -- time to write a function,
>
> say countdown(), that you can put where you need a count-down instead of the
>
> repetetive code.

Thanks so much,exactly what i was looking for
thanks for taking the time.




== 2 of 2 ==
Date: Thurs, Jan 9 2014 12:54 pm
From: Christopher Welborn


On 01/08/2014 11:56 PM, jeremiahvalerio123@gmail.com wrote:
> Hi, hows it going I've been self teaching myself python, and i typed up this small script now i know its not the best the coding is not the best but i would like to know of ways to make a small script like this better so all constructive critisim is Welcome.
>
>
>
> Here is the link to the code
>
> " http://pastebin.com/5uCFR2pz "
>

I'm not sure if someone already pointed this out, but imports only need
to be done once. Usually at the beginning of the file, but not always.
In your case I would say yes, at the beginning.

import sys
import time

def countdown(seconds):'
# start at 'seconds' and count down with a for-loop
for i in range(seconds, 0, -1):
# print the current second (i)
print('closing in {} seconds.'.format(i))
# sleep for one second (no need to import time again).
time.sleep(1)

# Example usage:
print('hello')
# Prints the countdown.
countdown(10)
sys.exit(0)
--

- Christopher Welborn <cjwelborn@live.com>
http://welbornprod.com





==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en