Re: Preventing crap email from google?
On Oct 20, 8:35 am, Michael Torrie wrote: > On 10/19/2012 06:43 PM, Mark Lawrence wrote: > > > Good morning/afternoon/evening all, > > > Is there any possibility that we could find a way to prevent the double > > spaced rubbish that comes from G$ infiltrating this ng/ml? For example, > > does Python have anybody who works for G$ who could pull a few strings, > > preferably a Dutch national who has named a quite well known programming > > language after a humorous BBC television programme? > > I don't know what G$ is, but from your subject, I assume you are > complaining about posts from gmail users, of which I am one. However my > messages have never been double-spaced. And I haven't noticed any > recently either. I just checked and the last dozen or so posts from > gmail accounts don't appear to have any problems. Heres something that has worked so far: Login to gmail Login to googlegroups in another tab Logout of gmail Reload the groups page -- your name which was on the left corner should be replaced by a sign-in And a 'wheel' The wheel should give you a choice for 'old' (aka non-buggy) interface -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On Oct 20, 8:27 am, Tim Chase wrote: > On 10/19/12 17:14, Steven D'Aprano wrote: > > > Code never *needs* to be long, because it can always be shortened. > > I advocate one bit per line: > > 1 > 0 > 1 > 0 > 0 > 1 > 0 > 1 > 1 > 0 > 0 > 1 > 0 > 1 > 1 > 1 > 0 > 0 > 0 > 0 > 1 > 1 > 1 > 0 > 1 > 1 > 0 > 0 > 1 > 1 > 0 > 1 > 1 > 0 > 0 > 1 > 1 > 1 > 1 > 0 > 0 > 1 > 1 > 1 > 1 > 1 > 1 > 1 > > «grins, ducks, and flees» > > Shortenedly-yers, > > -tkc T H A N K S T I M (for the sanity) -- http://mail.python.org/mailman/listinfo/python-list
How to see the __name__ attribute of a class by using dir()
The dir() built-in does not show the __name__ attribute of a class: >>> '__name__' in Foo.__dict__ False >>> Foo.__name__ 'Foo' I implementd my custom __dir__, but the dir() built-in do not want to call it: >>> class Foo: ... @classmethod ... def __dir__(cls): ... return ['python'] ... >>> Foo.__dir__() ['python'] >>> dir(Foo) ['__class__', '__delattr__', '__dict__', ...] Can someone tell me where is the problem? Thanks a lot in advance -- Jennie -- http://mail.python.org/mailman/listinfo/python-list
Re: How to see the __name__ attribute of a class by using dir()
Jennie wrote: > The dir() built-in does not show the __name__ attribute of a class: > > >>> '__name__' in Foo.__dict__ > False > >>> Foo.__name__ > 'Foo' > > I implementd my custom __dir__, but the dir() built-in do not want to > call it: > > >>> class Foo: > ... @classmethod > ... def __dir__(cls): > ... return ['python'] > ... > >>> Foo.__dir__() > ['python'] > >>> dir(Foo) > ['__class__', '__delattr__', '__dict__', ...] > > Can someone tell me where is the problem? Thanks a lot in advance Implementing __dir__ as an instance method works: >>> class Foo(object): ... def __dir__(self): return ["python"] ... >>> dir(Foo()) ['python'] So if you want to customise dir(Foo) you have to modify the metaclass: >>> class Foo: ... class __metaclass__(type): ... def __dir__(self): return ["python"] ... >>> dir(Foo) ['python'] -- http://mail.python.org/mailman/listinfo/python-list
Re: Preventing crap email from google?
On Sat, 2012-10-20, Michael Torrie wrote: > On 10/19/2012 06:43 PM, Mark Lawrence wrote: >> Good morning/afternoon/evening all, >> >> Is there any possibility that we could find a way to prevent the double >> spaced rubbish that comes from G$ infiltrating this ng/ml? For example, >> does Python have anybody who works for G$ who could pull a few strings, >> preferably a Dutch national who has named a quite well known programming >> language after a humorous BBC television programme? > > I don't know what G$ is, but from your subject, I assume you are > complaining about posts from gmail users, of which I am one. However my > messages have never been double-spaced. And I haven't noticed any > recently either. I just checked and the last dozen or so posts from > gmail accounts don't appear to have any problems. He's probably talking about Google Groups and its "integration" with Usenet. (I'm seeing this as the comp.lang.python newsgroup, via a real news reader and a real Usenet provider. I am vaguely aware that it's also a mailing list.) Google Groups has a long history of creating broken Usenet postings in new and exciting ways. It's at least as bad as MS Outlook Express and AOL were in Usenet's past. Your own posting (or mail) is almost flawless: correct quoting, and a properly formatted response. But you seem to be using gmail and the mailing list interface; that's not the technology he's complaining about. /Jorgen -- // Jorgen GrahnO o . -- http://mail.python.org/mailman/listinfo/python-list
Re: How to see the __name__ attribute of a class by using dir()
On 10/20/2012 10:24 AM, Peter Otten wrote: So if you want to customise dir(Foo) you have to modify the metaclass: >>>class Foo: ... class __metaclass__(type): ... def __dir__(self): return ["python"] ... >>>dir(Foo) ['python'] Hi Peter, thanks for your answer, but it does not work (Python 3.3): >>> class Foo: ... class __metaclass__(type): ... def __dir__(self): return ["python"] ... >>> dir(Foo) ['__class__', '__delattr__', '__dict__', '__dir__', ...] Regards, -- Jennie -- http://mail.python.org/mailman/listinfo/python-list
SQLObject 1.3.2 and 1.2.4
Hello! I'm pleased to announce versions 1.3 2 and 1.2.4, minor bugfix releases of SQLObject. What is SQLObject = SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB). Where is SQLObject == Site: http://sqlobject.org Development: http://sqlobject.org/devel/ Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://pypi.python.org/pypi/SQLObject/1.3.2 http://pypi.python.org/pypi/SQLObject/1.2.4 News and changes: http://sqlobject.org/News.html What's New == * Fixed a bug in sqlbuilder.Select.filter - removed comparison with SQLTrueClause. * Neil Muller fixed a number of tests. For a more complete list, please see the news: http://sqlobject.org/News.html Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to see the __name__ attribute of a class by using dir()
Jennie wrote: > On 10/20/2012 10:24 AM, Peter Otten wrote: > >> So if you want to customise dir(Foo) you have to modify the metaclass: >> > >>>class Foo: >> ... class __metaclass__(type): >> ... def __dir__(self): return ["python"] >> ... > >>>dir(Foo) >> ['python'] >> >> > > Hi Peter, thanks for your answer, but it does not work (Python 3.3): > > >>> class Foo: > ... class __metaclass__(type): > ... def __dir__(self): return ["python"] > ... > >>> dir(Foo) > ['__class__', '__delattr__', '__dict__', '__dir__', ...] In Python 3 the way to specify the metaclass has changed: >>> class FooType(type): ... def __dir__(self): return ["python"] ... >>> class Foo(metaclass=FooType): ... pass ... >>> dir(Foo) ['python'] -- http://mail.python.org/mailman/listinfo/python-list
Re: use of exec()
On Saturday, October 20, 2012 4:00:55 AM UTC+2, Chris Angelico wrote: > On Sat, Oct 20, 2012 at 10:43 AM, lars van gemerden > > wrote: > > > Do you have any ideas about to what extend the "lambda" version of the code > > (custom code is only the 'body' of the lambda function) has the same issues? > > > > The lambda version definitely has the same issues. You can do pretty > > much anything with a single expression. > > > > ChrisA Thanks a lot Chris, I will return later to the watchdog/memory limit ideas (no idea how to do that yet). -- http://mail.python.org/mailman/listinfo/python-list
Re: How to see the __name__ attribute of a class by using dir()
On 10/20/2012 11:43 AM, Peter Otten wrote: In Python 3 the way to specify the metaclass has changed: class FooType(type): ... def __dir__(self): return ["python"] ... class Foo(metaclass=FooType): ... pass ... dir(Foo) ['python'] Thanks! :) -- Jennie -- http://mail.python.org/mailman/listinfo/python-list
Re: Python on Windows
"Tim Golden" wrote: In general, you'll want to be using a mechanism such as pip: http://pypi.python.org/pypi/pip which will look things up on PyPI so you can just do "pip install newmodule". And if you have a pip.bat from some Perl installation sitting before python's Scripts dir in your %PATH, remember to use "pip.exe install newmodule" instead. My Strawberry Perl has this "Perl Installation Package". Maybe I should rearrange my %PATH? --gv -- http://mail.python.org/mailman/listinfo/python-list
Tips on Caring Adapter (Charger) Laptop
Charger or laptop adapter is often damaged when the use and improper storage. In fact, the adapter works for supplying power to the laptop, and if the conditions are not good can cause damage to your laptop. Use the correct adapter will help reduce the risk of damage to your laptop and keep money in your pocket in order not wasted, because of problems that cause laptop adapter is damaged. Tips on Caring Adapter: 1. Roll adapter properly, do not wrap the adapter box. Roll a good example is exemplified in the image below. 2. When using the adapter, make sure the cable is not pinched or crushed anything. Because it can damage the wires inside. 3. Do not roll up the cable too tight so that the base of the cord involved curled or bent. 4. Avoid wrapping the cord in the adapter, because of the risk at the base of the cable membengkoknya, more so if the adapter is carried in a bag. 5. When installing the adapter into the laptop if it feels hard, you should stop for a slanted mounting position will damage the jack jack jack adapter or laptop. 6. Keep the temperature adapter, multiple congenital laptop adapters often blistered when overheated. 7. If the adapter is often falter when used better soon replace the adapter. Since the adapter is much cheaper prices than buying a motherboard or a new battery. 8. Avoid the use of the power outlet voltage up and down, or use a stabilizer. 9. Perform charging battery before it runs out altogether because charging an empty battery will require a great power, it is to avoid heavy work adapter. Source : http://laptopworld21.blogspot.com/2012/10/tips-on-caring-adapter-charger-laptop.html -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On 2012-10-20, Dennis Lee Bieber wrote: > Strangely, we've gone from 80-character fixed width displays to > who-knows-what (if I drop my font size I can probably get nearly 200 > characters across in full-screen mode)... > > But at the same time we've gone from 132-character line-printers > using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11 > paper, defaulting to portrait orientation -- with a 10 character/inch > font, and 1/4" left/right margins, we're back to 80 character limitation > True, but nobody prints source code out on paper do they? Seriously -- I can't remember the last time I printed souce code... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: Preventing crap email from google?
On 2012-10-20, Michael Torrie wrote: > On 10/19/2012 06:43 PM, Mark Lawrence wrote: >> Good morning/afternoon/evening all, >> >> Is there any possibility that we could find a way to prevent the double >> spaced rubbish that comes from G$ infiltrating this ng/ml? For example, >> does Python have anybody who works for G$ who could pull a few strings, >> preferably a Dutch national who has named a quite well known programming >> language after a humorous BBC television programme? > > I don't know what G$ is, but from your subject, I assume you are > complaining about posts from gmail users, of which I am one. Postings from gmail users aren't a problem. Posts made via the google-groups web site are a problem, and I plonked them all years and years ago... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On 20 October 2012 15:18, Grant Edwards wrote: > On 2012-10-20, Dennis Lee Bieber wrote: > > > Strangely, we've gone from 80-character fixed width displays to > > who-knows-what (if I drop my font size I can probably get nearly 200 > > characters across in full-screen mode)... > > > > But at the same time we've gone from 132-character line-printers > > using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11 > > paper, defaulting to portrait orientation -- with a 10 character/inch > > font, and 1/4" left/right margins, we're back to 80 character limitation > > > > True, but nobody prints source code out on paper do they? > > Seriously -- I can't remember the last time I printed souce code... > The A-level computing syllabus requires you to. A friend of mine who took the course ended up with a 200+ page binder. Just saying. -- http://mail.python.org/mailman/listinfo/python-list
Interest in seeing sh.py in the stdlib
Hi, I'm the author of sh.py, a subprocess module rewrite for Linux and OSX. It serves as a powerful and intuitive interface to launching subprocesses http://amoffat.github.com/sh/. It has been maintained on github https://github.com/amoffat/sh for about 10 months and currently has about 25k installs, according to pythonpackages.com. Andy Grover maintains the Fedora rpm for sh.py http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=94247 and Nick Moffit has submitted an older version of sh.py (which was called pbs) to be included in Debian distros http://pkgs.org/debian-wheezy/debian-main-i386/python-pbs_0.95-1_all.deb.html I'm interested in making sh.py more accessible to help bring Python forward in the area of shell scripting, so I'm interested in seeing if sh would be suitable for the standard library. Is there any other interest in something like this? Thanks Andrew Moffat -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On Sat, Oct 20, 2012 at 3:10 PM, Dennis Lee Bieber wrote: > On Sat, 20 Oct 2012 14:18:47 + (UTC), Grant Edwards > declaimed the following in > gmane.comp.python.general: > >> >> True, but nobody prints source code out on paper do they? >> >> Seriously -- I can't remember the last time I printed souce code... > > Well, having been unemployed for a year, I can't speak much of > recent practice... > > But I did tend to run up listings when I had to take over > maintenance of some programs and needed to become familiar with the > overall code base... Same here. I've been unemployed (retired!) 6 years, but I'd occasionally print code written by someone else, never anything of my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
On Sat, 20 Oct 2012 14:18:47 +, Grant Edwards wrote: > True, but nobody prints source code out on paper do they? > > Seriously -- I can't remember the last time I printed souce code... I remember my first IT job - COBOL programming in the early 80's. The rule was that every time we delivered a new or updated program into testing, we had to print a listing onto fanfold paper and hang it, in a cardboard binder, onto a set of rails which ran down the center of the office. I recall even then thinking the practice ludicrous. -- http://mail.python.org/mailman/listinfo/python-list
Re: Preventing crap email from google?
On Sat, 20 Oct 2012 01:43:03 +0100, Mark Lawrence wrote: > Good morning/afternoon/evening all, > > Is there any possibility that we could find a way to prevent the double > spaced rubbish that comes from G$ infiltrating this ng/ml? For example, > does Python have anybody who works for G$ who could pull a few strings, > preferably a Dutch national who has named a quite well known programming > language after a humorous BBC television programme? It is Google bloody Groups which is the problem. I should have plonked posts from there ages ago, and am about to remedy that omission. -- http://mail.python.org/mailman/listinfo/python-list
Re: A desperate lunge for on-topic-ness
In article <[email protected]>, Steven D'Aprano wrote: > Some code might be more conveniently written as a single long line. But I > would argue that nearly never is code more easily *read* as a single long > line, and since code is read much more than it is written, it is more > important to optimise for reading, not writing. Like many people here, I don't worry much about the 80 column limit. I make my lines of code as long as they have to be, and no longer. If there's some obvious and easy way to fold the statement onto multiple lines, I'll do it. If not, I won't. This tends to result in lines that are less than 80 characters, but if not, I don't worry about it (assuming I'm even aware of it). I just did a little experiment. I took about 20 KLOC of python that was largely written by me and make a histogram of the line lengths (http://www.panix.com/~roy/length.pdf). Just by eye, I'd say "most are less than 80, almost all are less than 100". I'd guess the average of all non-empty lines is about 45 or so. The longest line is 273 characters: sys.stderr.write("Error: Can't find the file 'settings.py' in the directory containing %r.\nYou'll have to run django-profile.py, passing it your settings module.\n(If the file settings.py does indeed exist, it's causing an ImportError somehow.)\n" % __file__) Would that have been better rewritten broken up into several shorter lines? Absolutely. Such is life. PS: I didn't write that line :-) -- http://mail.python.org/mailman/listinfo/python-list
Preserving unicode filename encoding
Hi, I've noticed that the encoding of non-ascii filenames can be inconsistent between platforms when using the built-in open() function to create files. For example, on a Ubuntu 10.04.4 LTS box, the character u'ş' (u'\u015f') gets encoded as u'ş' (u's\u0327'). Note how the two characters look exactly the same but are encoded differently. The original character uses only one code (u'\u015f'), but the resulting character that is saved on the file system will be made of a combination of two codes: the letter 's' followed by a diacritical cedilla (u's\u0327'). (You can learn more about diacritics in [1]). On the Mac, however, the original encoding is always preserved. This issue was also discussed in a blog post by Ned Batchelder [2]. One suggested approach is to normalize the filename, however this could result in loss of information (what if, for example, the original filename did contain combining diacritics and we wanted to preserve them). Ideally, it would be preferable to preserve the original encoding. Is that possible or is that completely out of Python's control? Thanks a lot, Julien [1] http://en.wikipedia.org/wiki/Combining_diacritic#Unicode_ranges [2] http://nedbatchelder.com/blog/201106/filenames_with_accents.html -- http://mail.python.org/mailman/listinfo/python-list
'generator ignored GeneratorExit''
If I run the following code in the same module, it works correctly, but
if I import it I get the message:
Exception RuntimeError: 'generator ignored GeneratorExit' in object getNxtFile at 0x7f932f884f50> ignored
def getNxtFile (startDir, exts = ["txt", "utf8"]):
try:
forpathingetNxtPath (startDir, exts):
try:
fil=open (path, encoding = "utf-8-sig")
yieldfil
except:
print ("Could not read: ", path)
exceptGeneratorExit:
raiseStopIteration
The message appears to be purely informational, but I *would* like to
fix whatever problem it's reporting, and none of the changes that I've
tried have worked. What *should* I be doing?
--
Charles Hixson
--
http://mail.python.org/mailman/listinfo/python-list
Re: 'generator ignored GeneratorExit''
On 2012-10-20 21:03, Charles Hixson wrote:
If I run the following code in the same module, it works correctly, but
if I import it I get the message:
Exception RuntimeError: 'generator ignored GeneratorExit' in ignored
def getNxtFile (startDir, exts = ["txt", "utf8"]):
try:
forpathingetNxtPath (startDir, exts):
try:
fil=open (path, encoding = "utf-8-sig")
yieldfil
except:
print ("Could not read: ", path)
exceptGeneratorExit:
raiseStopIteration
The message appears to be purely informational, but I *would* like to
fix whatever problem it's reporting, and none of the changes that I've
tried have worked. What *should* I be doing?
That code has a bare except, which is virtually always a bad idea
because it swallows _all_ exceptions. Maybe, in this case, it's
swallowing an exception that would tell you the cause of the problem.
--
http://mail.python.org/mailman/listinfo/python-list
Re: change the first letter into uppercase (ask)
the pattern `re.compile(".(?#nyh2p){0,1}")` , make me confused,
can you explain how it can match the first letter of every word?
2012/10/20 Dennis Lee Bieber
> On Sat, 20 Oct 2012 01:03:46 -0400, Zero Piraeus
> declaimed the following in gmane.comp.python.general:
>
> > :
> >
> > On 20 October 2012 00:09, contro opinion wrote:
> > > how can i use regular expression in python to change the string
> > > "a test of capitalizing"
> > > into
> > > "A Test Of Capitalizing"?
> >
> > >>> import re
> > >>> pattern = re.compile(".(?#nyh2p){0,1}")
> > >>> result = ""
> > >>> f = str.title
>
> f = str.capitalize
>
> > >>> for match in re.findall(pattern, "a test of capitalizing"):
> > ... result = f(result + match)
>
> result = result + f(match)
>
> Or closer... Don't both with f and str.capitalize
>
> result = result + match.capitalize()
>
> > ...
> > >>> print(result)
> > A Test Of Capitalizing
> > >>>
> >
>
>
> >>> "a test of capitalizing".title()
> 'A Test Of Capitalizing'
> >>>
>
> Not to be confused with
>
> >>> "a test of capitalizing".capitalize()
> 'A test of capitalizing'
> >>>
> --
> Wulfraed Dennis Lee Bieber AF6VN
> [email protected]://wlfraed.home.netcom.com/
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
SQLAlchemy: How to do Table Reflection and MySQL?
Hi, I'm fairly new to Python, and I'm trying to figure out how to use SQLAlchemy to connect to a MySQL DB and use table reflection to set up SQLAlchemy's tables. But the SQLAlchemy documentation is gigantic and frankly kinda making my head spin, so I'm having trouble even finding any information on how to use its table reflection, mostly just that it exists and *can* be done, but not so much "how". My web searching has just been turning up examples of SQLite and manually describing the tables in Python and having SQLAlchemy create the tables, which isn't what I'm looking for. Is there a simple way to do this somehow? To just connect to a MySQL DB and use table reflection? -- http://mail.python.org/mailman/listinfo/python-list
Re: 'generator ignored GeneratorExit''
On Sat, Oct 20, 2012 at 2:03 PM, Charles Hixson
wrote:
> If I run the following code in the same module, it works correctly, but if I
> import it I get the message:
> Exception RuntimeError: 'generator ignored GeneratorExit' in object getNxtFile at 0x7f932f884f50> ignored
>
> def getNxtFile (startDir, exts = ["txt", "utf8"]):
> try:
> forpathingetNxtPath (startDir, exts):
> try:
> fil=open (path, encoding = "utf-8-sig")
> yieldfil
> except:
> print ("Could not read: ", path)
> exceptGeneratorExit:
> raiseStopIteration
>
> The message appears to be purely informational, but I *would* like to fix
> whatever problem it's reporting, and none of the changes that I've tried
> have worked. What *should* I be doing?
The bare except is probably catching the GeneratorExit exception and
swallowing it. Try catching a more specific exception like OSError or
even just Exception instead.
Also, you don't need to explicitly catch GeneratorExit just to raise
StopIteration. The generator will normally stop on GeneratorExit,
provided the exception is actually able to propagate up.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Preserving unicode filename encoding
On Sat, 20 Oct 2012 13:43:16 -0700, Julien Phalip wrote:
> I've noticed that the encoding of non-ascii filenames can be inconsistent
> between platforms when using the built-in open() function to create files.
>
> For example, on a Ubuntu 10.04.4 LTS box, the character u'ş' (u'\u015f')
> gets encoded as u'ş' (u's\u0327'). Note how the two characters look
> exactly the same but are encoded differently. The original character uses
> only one code (u'\u015f'), but the resulting character that is saved on
> the file system will be made of a combination of two codes: the letter 's'
> followed by a diacritical cedilla (u's\u0327'). (You can learn more about
> diacritics in [1]). On the Mac, however, the original encoding is always
> preserved.
>
> This issue was also discussed in a blog post by Ned Batchelder [2].
You are conflating two distinct issues here: representation (how a
given "character" is represented as a Unicode string) and encoding (how a
given Unicode string is represented as a byte string).
E.g. you state:
> For example, on a Ubuntu 10.04.4 LTS box, the character u'ş' (u'\u015f')
> gets encoded as u'ş' (u's\u0327').
which is incorrect.
The latter isn't an "encoding" of the former. They are alternate Unicode
representations of the same character. The former uses a pre-composed
character (LATIN SMALL LETTER S WITH CEDILLA) while the latter uses a
letter 's' with a combining accent (COMBINING CEDILLA).
Unlike the Mac, neither Unix nor Windows will automatically normalise
Unicode strings. A Unix filename is a sequence of bytes, nothing more and
nothing less. This is part of the reason why Unix filenames are case
sensitive: case applies to characters, and the kernel doesn't know which
characters, if any, those bytes are meant to represent.
Python will convert a Unicode string to a sequence of bytes using the
filesystem encoding. If the encoding is UTF-8, then u'\u015f'
will be encoded as b'\xc5\x9f', while u's\u0327' will be encoded as
b's\xcc\xa7'.
If you want to convert a Unicode string to a given normalisation, you can
use unicodedata.normalize(), e.g.:
> unicodedata.normalize('NFC', 's\u0327')
'\u015f'
> unicodedata.normalize('NFD', '\u015f')
's\u0327'
However: if you want to access an existing file, you must use the filename
as it appears on disc. On Unix and Windows, it's perfectly possible to
have two files named e.g. '\u015f.txt' and 's\u0327.txt' in the same
directory. Which one gets opened depends upon the exact sequence of
Unicode codepoints passed to open().
The situation is different on the Mac, where system libraries
automatically impose a specific representation on filenames, and will
normalise Unicode strings to that representation.
--
http://mail.python.org/mailman/listinfo/python-list
Re: change the first letter into uppercase (ask)
On Sat, Oct 20, 2012 at 5:14 PM, contro opinion wrote:
> the pattern `re.compile(".(?#nyh2p){0,1}")` , make me confused,
> can you explain how it can match the first letter of every word?
It doesn't.
>>> pattern = re.compile(".(?#nyh2p){0,1}")
>>> pattern.findall("a test of capitalizing")
['a', ' ', 't', 'e', 's', 't', ' ', 'o', 'f', ' ', 'c', 'a', 'p', 'i',
't', 'a', 'l', 'i', 'z', 'i', 'n', 'g', '']
The regex is just convolution. The solution actually works by calling
str.title(). The fact that it calls it 23 times instead of once is
further convolution.
--
http://mail.python.org/mailman/listinfo/python-list
Re: change the first letter into uppercase (ask)
On 2012-10-21 00:14, contro opinion wrote:
the pattern `re.compile(".(?#nyh2p){0,1}")` , make me confused,
can you explain how it can match the first letter of every word?
It matches all of the characters, plus an empty string at the end. It's
equivalent to:
result = ""
for c in "a test of capitalizing":
result = (result + c).title()
result = (result + "").title()
or:
result = "a test of capitalizing".title()
but somewhat slower...
2012/10/20 Dennis Lee Bieber mailto:[email protected]>>
On Sat, 20 Oct 2012 01:03:46 -0400, Zero Piraeus mailto:[email protected]>>
declaimed the following in gmane.comp.python.general:
> :
>
> On 20 October 2012 00:09, contro opinion mailto:[email protected]>> wrote:
> > how can i use regular expression in python to change the string
> > "a test of capitalizing"
> > into
> > "A Test Of Capitalizing"?
>
> >>> import re
> >>> pattern = re.compile(".(?#nyh2p){0,1}")
> >>> result = ""
> >>> f = str.title
f = str.capitalize
> >>> for match in re.findall(pattern, "a test of capitalizing"):
> ... result = f(result + match)
result = result + f(match)
Or closer... Don't both with f and str.capitalize
result = result + match.capitalize()
> ...
> >>> print(result)
> A Test Of Capitalizing
> >>>
>
>>> "a test of capitalizing".title()
'A Test Of Capitalizing'
>>>
Not to be confused with
>>> "a test of capitalizing".capitalize()
'A test of capitalizing'
>>>
--
http://mail.python.org/mailman/listinfo/python-list
Re: change the first letter into uppercase (ask)
On Sat, Oct 20, 2012 at 1:30 PM, Dennis Lee Bieber wrote: >> >>> for match in re.findall(pattern, "a test of capitalizing"): >> ... result = f(result + match) > > result = result + f(match) > > Or closer... Don't both with f and str.capitalize > > result = result + match.capitalize() These result in a string that is all-caps, not title-case. -- http://mail.python.org/mailman/listinfo/python-list
Re: 'generator ignored GeneratorExit''
On 10/20/2012 04:28 PM, Ian Kelly wrote:
On Sat, Oct 20, 2012 at 2:03 PM, Charles Hixson
wrote:
If I run the following code in the same module, it works correctly, but if I
import it I get the message:
Exception RuntimeError: 'generator ignored GeneratorExit' in ignored
def getNxtFile (startDir, exts = ["txt", "utf8"]):
try:
forpathingetNxtPath (startDir, exts):
try:
fil=open (path, encoding = "utf-8-sig")
yieldfil
except:
print ("Could not read: ", path)
exceptGeneratorExit:
raiseStopIteration
The message appears to be purely informational, but I *would* like to fix
whatever problem it's reporting, and none of the changes that I've tried
have worked. What *should* I be doing?
The bare except is probably catching the GeneratorExit exception and
swallowing it. Try catching a more specific exception like OSError or
even just Exception instead.
Also, you don't need to explicitly catch GeneratorExit just to raise
StopIteration. The generator will normally stop on GeneratorExit,
provided the exception is actually able to propagate up.
Thank you. That was, indeed the problem. Removing all the try ...
excepts made it work on my test case. Now I've got to figure out what
to catch in case it's not a utf8 file. I guess that I'll hope that
IOError will work, as nothing else sounds reasonable. It's general
enough that it ought to work.
--
Charles Hixson
--
http://mail.python.org/mailman/listinfo/python-list
Re: 'generator ignored GeneratorExit''
On 20Oct2012 16:41, Charles Hixson wrote: | On 10/20/2012 04:28 PM, Ian Kelly wrote: | > On Sat, Oct 20, 2012 at 2:03 PM, Charles Hixson | >> try: | >> fil=open (path, encoding = "utf-8-sig") | >> yieldfil | >> except: [...] | > The bare except is probably catching the GeneratorExit exception and | > swallowing it. Try catching a more specific exception like OSError or | > even just Exception instead. [...] | | Thank you. That was, indeed the problem. Removing all the try ... | excepts made it work on my test case. Now I've got to figure out what | to catch in case it's not a utf8 file. I guess that I'll hope that | IOError will work, as nothing else sounds reasonable. It's general | enough that it ought to work. No no no! Feed it a bad file and _watch_ what exception it throws. IIRC, it should throw a very specific UnicodeDecodingError; catch that and only that. Always try to catch the most specific exception possible or you're back in the same zone your bare except was in - catching things other than the specific problem you're handling. "General enough that it ought to work" is the wrong approach; "Exception" is general enough, and clearly the wrong approach. Catch exactly what you have to catch. Catching the wrong thing (another exception type) and _mishandling_ it (because you're treating it like a decoding error) is not "working", it is "not working". If you don't know the exception, let it bubble up and escape - Python will report it (and abort, of course). Cheers, -- Performing random acts of moral ambiguity. - Jeff Miller -- http://mail.python.org/mailman/listinfo/python-list
Re: 'generator ignored GeneratorExit''
On 21/10/12 01:41:37, Charles Hixson wrote:
> On 10/20/2012 04:28 PM, Ian Kelly wrote:
>> On Sat, Oct 20, 2012 at 2:03 PM, Charles Hixson
>> wrote:
>>> If I run the following code in the same module, it works correctly,
>>> but if I
>>> import it I get the message:
>>> Exception RuntimeError: 'generator ignored GeneratorExit' in>> object getNxtFile at 0x7f932f884f50> ignored
>>>
>>> def getNxtFile (startDir, exts = ["txt", "utf8"]):
>>> try:
>>> forpathingetNxtPath (startDir, exts):
>>> try:
>>> fil=open (path, encoding = "utf-8-sig")
>>> yieldfil
>>> except:
>>> print ("Could not read: ", path)
>>> exceptGeneratorExit:
>>> raiseStopIteration
>>>
>>> The message appears to be purely informational, but I *would* like to
>>> fix
>>> whatever problem it's reporting, and none of the changes that I've tried
>>> have worked. What *should* I be doing?
>> The bare except is probably catching the GeneratorExit exception and
>> swallowing it. Try catching a more specific exception like OSError or
>> even just Exception instead.
>>
>> Also, you don't need to explicitly catch GeneratorExit just to raise
>> StopIteration. The generator will normally stop on GeneratorExit,
>> provided the exception is actually able to propagate up.
> Thank you. That was, indeed the problem. Removing all the try ...
> excepts made it work on my test case. Now I've got to figure out what
> to catch in case it's not a utf8 file. I guess that I'll hope that
> IOError will work, as nothing else sounds reasonable. It's general
> enough that it ought to work.
I would expect a UnicideError, which is a subclass of ValueError,
but not of IOError. And I'd expect it to be raised when you start
reading the file, not when you open it.
The easiest way to find out this sort of thing, is to not have any
"except" clauses in your code. That way, the interpreter will tell
you exactly what was raised, and where. Much easier than guessing.
>>> import sys
>>> fil = open(sys.executable, encoding="utf8")
>>> fil.readline()
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/codecs.py",
line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xca in position 0:
invalid continuation byte
As I expected, opening a non-utf8 file succeeds, but readline() fails.
Hope this helps,
-- HansM
--
http://mail.python.org/mailman/listinfo/python-list
Re: pls help me with this prog
inshu chauhan wrote: > >but i want to calculate it for every 3 points not the whole data, but >instead of giving me centre for every 3 data the prog is printing the >centre 3 times... > >def main (data): >j = 0 >for i in data[:3]: >while j != 3: > centre = CalcCentre(data) > j += 1 > print centre This loop doesn't do what you think it does. Think about the problem you have to solve. You have a set of data. You want to operate on the whole set, 3 points at a time. What this loop does is grab the first three points (only), then calculates the center on the entire list three times. You want something like: # As long as there is data in the list: while data: # Split the list into two parts: first 3 and the rest. first3, data = data[3:],data[3:] # Operate on the first three. print CalcCenter( first3 ) To make it a little more resilient, you might make sure that len(data) is a multiple of 3, or at least stop when it is shorter than 3. To be more clever, you can write a function that returns 3 at a time: def N_at_a_time( iter, n ): while len(iter) >= n: yield iter[:n] iter = iter[n:] Now you can do this: def main(data): for first3 in N_at_a_time(data, 3): print CalcCenter(first3) -- Tim Roberts, [email protected] Providenza & Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: overriding equals operation
On 17 October 2012 09:14, Mark Lawrence wrote: > On 17/10/2012 05:16, 8 Dihedral wrote: > >> What you really want is b=a.copy() >> not b=a to disentangle two objects. >> >> __eq__ is used in the comparison operation. >> >> > The winner Smartest Answer by a Bot Award 2012 :) Something seems fishy here... I swear, either bots are becoming sentient or 8 isn't always a bot. He easily passed the Turing test right there. -- http://mail.python.org/mailman/listinfo/python-list
