On 05/30/2012 09:07 AM, ru...@yahoo.com wrote:
On 05/30/2012 05:54 AM, Thomas Rachel wrote:
Am 30.05.2012 08:52 schrieb ru...@yahoo.com:
This breaks a lot of my code because in python 2
re.split (ur'[\u3000]', u'A\u3000A') == [u'A', u'A']
but in python 3 (the result of running 2to3
On 05/31/2012 03:10 PM, Chris Angelico wrote:
On Fri, Jun 1, 2012 at 6:28 AM, ru...@yahoo.com ru...@yahoo.com wrote:
... a lexer module that is structured as many
dozens of little functions, each with a docstring that is
a regex string.
This may be a good opportunity to take a step back
In python2, \u escapes are processed in raw unicode
strings. That is, ur'\u3000' is a string of length 1
consisting of the IDEOGRAPHIC SPACE unicode character.
In python3, \u escapes are not processed in raw strings.
r'\u3000' is a string of length 6 consisting of a backslash,
'u', '3' and three
On 05/30/2012 05:54 AM, Thomas Rachel wrote:
Am 30.05.2012 08:52 schrieb ru...@yahoo.com:
This breaks a lot of my code because in python 2
re.split (ur'[\u3000]', u'A\u3000A') == [u'A', u'A']
but in python 3 (the result of running 2to3),
re.split (r'[\u3000]', 'A\u3000A
On 05/30/2012 10:46 AM, Terry Reedy wrote:
On 5/30/2012 2:52 AM, ru...@yahoo.com wrote:
In python2, \u escapes are processed in raw unicode
strings. That is, ur'\u3000' is a string of length 1
consisting of the IDEOGRAPHIC SPACE unicode character.
That surprised me until I rechecked
What is this output from 2to3 supposed to mean?
$ cat mysub.py
isinstance (3, (int,float))
$ 2to3 -f isinstance mysub.py
RefactoringTool: No changes to mysub.py
RefactoringTool: Files that need to be modified:
RefactoringTool: mysub.py
Why does mysub.py need to be modified, and how?
On 05/27/2012 07:53 AM, Steven D'Aprano wrote:
On Sat, 26 May 2012 19:37:33 -0700, ru...@yahoo.com wrote:
Is there a list of fixers I can tell 2to3 to use that will limit changes
to things that will continue to run under python-2.7?
So you want a 2to2?
Yes. :-)
I suggest you read
Is there a list of fixers I can tell 2to3 to use that will
limit changes to things that will continue to run under
python-2.7?
I want to start the 2-3 trip by making my code
as py3 compatible (under py2) as possible before
going the rest of the way to py3, and having 2to3
help with this seems
On 04/30/2012 05:24 PM, deltaquat...@gmail.com wrote:
Hi,
I would like to automate some simple tasks I'm doing by hand. Given a text
file
foobar.fo:
073 1.819
085 2.132
100 2.456
115 2.789
I need to create the directories 073, 085, 100, 115, and copy in each
directory a modified
I have optparse code that parses a command line containing
intermixed positional and optional arguments, where the optional
arguments set the context for the following positional arguments.
For example,
myprogram.py arg1 -c33 arg2 arg3 -c44 arg4
'arg1' is processed in a default context,
On Jan 5, 1:05 am, ru...@yahoo.com ru...@yahoo.com wrote:
class AppendWithPos (argparse.Action):
def __call__ (self, parser, namespace, values,
option_string=None):
if getattr (namespace, self.dest, None) is None:
setattr (namespace, self.dest, [])
getattr
On 01/05/2012 02:19 AM, Ulrich Eckhardt wrote:
Am 05.01.2012 09:05, schrieb ru...@yahoo.com:
I have optparse code that parses a command line containing
intermixed positional and optional arguments, where the optional
arguments set the context for the following positional arguments
On 01/05/2012 11:46 AM, Ian Kelly wrote:
On Thu, Jan 5, 2012 at 11:14 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, Jan 5, 2012 at 1:05 AM, ru...@yahoo.com ru...@yahoo.com wrote:
I have optparse code that parses a command line containing
intermixed positional and optional arguments, where
On Dec 13, 5:32 am, Stefan Behnel stefan...@behnel.de wrote:
...
In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method=c14n.
Where in the Python docs can one find information about this?
[previous post disappeared, sorry if I double posted or replied to
On Dec 13, 5:32 am, Stefan Behnel stefan...@behnel.de wrote:
...
In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method=c14n.
Where does one find information in the Python documentation about
this?
--
http://mail.python.org/mailman/listinfo/python-list
On Dec 13, 1:21 pm, Stefan Behnel stefan...@behnel.de wrote:
ru...@yahoo.com, 13.12.2011 20:37:
On Dec 13, 5:32 am, Stefan Behnel wrote:
In Python 2.7/3.2, ElementTree has support for C14N serialisation, just
pass the option method=c14n.
Where does one find information in the Python
On 10/14/2011 03:29 PM, Peng Yu wrote:
Hi,
The following code doesn't give me error, even I don't specify the
value of filename from the command line arguments. filename gets
'None'. I checked the manual, but I don't see a way to let
OptionParser fail if an argument's value (which has no
On 08/19/2011 11:33 AM, Matt Funk wrote:
On Friday, August 19, 2011, Alain Ketterlin wrote:
Matt Funk matze...@gmail.com writes:
thanks for the suggestion. I guess i had found another way around the
problem as well. But i really wanted to match the line exactly and i
wanted to know why it
On 06/08/2011 03:01 AM, Duncan Booth wrote:
ru...@yahoo.com ru...@yahoo.com wrote:
On 06/06/2011 09:29 AM, Steven D'Aprano wrote:
Yes, but you have to pay the cost of loading the re engine, even if
it is a one off cost, it's still a cost,
[...]
At least part of the reason that there's
On 06/07/2011 06:30 PM, Roy Smith wrote:
On 06/06/2011 08:33 AM, rusi wrote:
Evidently for syntactic, implementation and cultural reasons, Perl
programmers are likely to get (and then overuse) regexes faster than
python programmers.
ru...@yahoo.com ru...@yahoo.com wrote:
I don't see how
On 06/06/2011 09:29 AM, Steven D'Aprano wrote:
On Sun, 05 Jun 2011 23:03:39 -0700, ru...@yahoo.com wrote:
[...]
I would argue that the first, non-regex solution is superior, as it
clearly distinguishes the multiple steps of the solution:
* filter lines that start with CUSTOMER
* extract
On 06/06/2011 08:33 AM, rusi wrote:
For any significant language feature (take recursion for example)
there are these issues:
1. Ease of reading/skimming (other's) code
2. Ease of writing/designing one's own
3. Learning curve
4. Costs/payoffs (eg efficiency, succinctness) of use
5.
On 06/03/2011 08:05 PM, Steven D'Aprano wrote:
On Fri, 03 Jun 2011 12:29:52 -0700, ru...@yahoo.com wrote:
I often find myself changing, for example, a startwith() to a RE when
I realize that the input can contain mixed case
Why wouldn't you just normalise the case?
Because some of the text
On 06/03/2011 02:49 PM, Neil Cerutti wrote:
On 2011-06-03, ru...@yahoo.com ru...@yahoo.com wrote:
or that I have to treat commas as well as spaces as
delimiters.
source.replace(,, ).split( )
Uhgg. create a whole new string just so you can split it on one
rather than two characters
On 06/03/2011 03:45 PM, Chris Torek wrote:
On 2011-06-03, ru...@yahoo.com ru...@yahoo.com wrote:
[prefers]
re.split ('[ ,]', source)
This is probably not what you want in dealing with
human-created text:
re.split('[ ,]', 'foo bar, spam,maps')
['foo', '', 'bar', '', 'spam
On 06/02/2011 07:21 AM, Neil Cerutti wrote:
On 2011-06-01, ru...@yahoo.com ru...@yahoo.com wrote:
For some odd reason (perhaps because they are used a lot in
Perl), this groups seems to have a great aversion to regular
expressions. Too bad because this is a typical problem where
On 06/03/2011 07:17 AM, Neil Cerutti wrote:
On 2011-06-03, ru...@yahoo.com ru...@yahoo.com wrote:
The other tradeoff, applying both to Perl and Python is with
maintenance. As mentioned above, even when today's
requirements can be solved with some code involving several
string functions
On 06/03/2011 08:25 AM, Steven D'Aprano wrote:
On Fri, 03 Jun 2011 05:51:18 -0700, ru...@yahoo.com wrote:
On 06/02/2011 07:21 AM, Neil Cerutti wrote:
Python's str methods, when they're sufficent, are usually more
efficient.
Unfortunately, except for the very simplest cases
On Jun 1, 11:11 am, Chris Rebert c...@rebertia.com wrote:
On Wed, Jun 1, 2011 at 12:31 AM, rakesh kumar
Hi
i have a file which contains data
//ACCDJ EXEC DB2UNLDC,DFLID=DFLID,PARMLIB=PARMLIB,
// UNLDSYST=UNLDSYST,DATABAS=MBQV1D0A,TABLE='ACCDJ '
//ACCT
On 05/12/2011 12:13 AM, Steven D'Aprano wrote:
[snip]
http://www.codinghorror.com/blog/2006/07/separating-programming-sheep-from-non-programming-goats.html
Shorter version: it seems that programming aptitude is a bimodal
distribution, with very little migration from the can't program hump
On 01/04/2011 11:29 PM, Steven D'Aprano wrote:
On Tue, 04 Jan 2011 15:17:37 -0800, ru...@yahoo.com wrote:
If one wants to critique the 'Python Docs', especially as regards to
usefulness to beginners, one must start with the Tutorial; and if one
wants to use if statements as an example, one
On 01/05/2011 12:23 AM, Alice Bevan–McGregor wrote:
On 2011-01-04 22:29:31 -0800, Steven D'Aprano said:
In any case, your assumption that any one documentation work should stand
on its own merits is nonsense -- *nothing* stands alone.
+1
I responded more fully in my response to Steven
On 01/04/2011 01:34 PM, Terry Reedy wrote:
On 1/4/2011 1:24 PM, an Arrogant Ignoramus wrote:
what he called
a opinion piece.
I normally do not respond to trolls, but while expressing his opinions,
AI made statements that are factually wrong at least as regards Python
and its practitioners.
On 09/02/2010 02:47 PM, Terry Reedy wrote:
On 9/1/2010 10:57 PM, ru...@yahoo.com wrote:
So while you may think most people rarely read
the docs for basic language features and objects
(I presume you don't mean to restrict your statement
to only sets), I and most people I know *do* read
them
On 09/01/2010 04:51 PM, Raymond Hettinger wrote:
On Aug 30, 6:03 am, a...@pythoncraft.com (Aahz) wrote:
That reminds me: one co-worker (who really should have known better ;-)
had the impression that sets were O(N) rather than O(1). Although
writing that off as a brain-fart seems appropriate,
On 08/30/2010 04:50 AM, Thomas Jollans wrote:
On Monday 30 August 2010, it occurred to ru...@yahoo.com to exclaim:
Face the facts dude. The Python docs have some major problems.
They were pretty good when Python was a new, cool, project used
by a handful of geeks. They are good relative
On 08/30/2010 01:14 PM, Terry Reedy wrote:
On 8/30/2010 12:23 AM, ru...@yahoo.com wrote:
The Python docs have some major problems.
And I have no idea what you think they are.
I have written about a few of them here in the past. I sure Google
will
turn up something.
I have participated
On 08/29/2010 08:21 PM, alex23 wrote:
kj no.em...@please.post wrote:
snip
Sorry for the outburst, but unfortunately, PIL is not alone in
this. Python is awash in poor documentation. [...]
I have to conclude that the problem with Python docs
is somehow systemic...
Yes, if everyone else
On Jun 30, 10:48 am, John Nagle na...@animats.com wrote:
On 6/30/2010 12:13 AM, Дамјан Георгиевски wrote:
A 'raise-yield' expression would break the flow of a program just like
an exception, going up the call stack until it would be handled, but
also like yield it would be possible to
On Jun 30, 9:42 am, Michele Simionato michele.simion...@gmail.com
wrote:
Actually when debugging I use pdb which uses p (no parens) for
printing, so having
print or print() would not make any difference for me.
Perhaps you don't use CJK strings much?
p u'\u30d1\u30a4\u30c8\u30f3' give quite
40 matches
Mail list logo
