headers
noydb | 10 Feb 03:25
Picon
Gravatar

Re: round down to nearest number

That {>>> (3219 + 99) // 100} doesnt work if the number is other then
4 digits.

(for rounding up to nearest 100):
>>> (3219 + 99)//100
33
>>> (3289 + 99)//100
33
>>> (328678 + 99)//100
3287
>>> (328 + 99)//100
4
Permalink | Reply | 1 comment |
headers
noydb | 10 Feb 02:23
Picon
Gravatar

Re: round down to nearest number

hmmm, okay.

So how would you round UP always?  Say the number is 3219, so you want
3300 returned.
Permalink | Reply | 6 comments |
headers
Steven D'Aprano | 10 Feb 02:24

Re: frozendict

On Thu, 09 Feb 2012 09:35:52 -0700, Ian Kelly wrote:

> On Thu, Feb 9, 2012 at 8:19 AM, Nathan Rice
> <nathan.alexander.rice <at> gmail.com> wrote:
>> As I said, two dictionaries created from the same input will be the
>> same...
> 
> That's an implementation detail, not a guarantee.  It will hold for
> current versions of CPython but not necessarily for other Python
> implementations.

That day may be sooner than you think. It is very likely that in Python 
3.3, dict order will be randomized on creation as a side-effect of adding 
a random salt to hashes to prevent a serious vulnerability in dicts.

http://securitytracker.com/id/1026478

http://bugs.python.org/issue13703

If there is anyone still assuming that dicts have a predictable order, 
they're going to be in for a nasty surprise one of these days.

--

-- 
Steven
Permalink | Reply | 2 comments |
headers
noydb | 10 Feb 01:30
Picon
Gravatar

round down to nearest number

How do you round down ALWAYS to nearest 100?  Like, if I have number
3268, I want that rounded down to 3200.  I'm doing my rounding like
>>> round(3268, -2)
But, how to round DOWN?
Permalink | Reply | 1 comment |
headers
jkn | 10 Feb 00:24
Picon
Gravatar

Re: multiple namespaces within a single module?

Hi Peter

On Feb 9, 7:33 pm, Peter Otten <__pete...@web.de> wrote:
> jkn wrote:
> >     is it possible to have multiple namespaces within a single python
> > module?
>
> Unless you are abusing classes I don't think so.
>
> > I have a small app which is in three or four .py files. For various
> > reasons I would like to (perhaps optionally) combine these into one
> > file.
>
> Rename your main script into __main__.py, put it into a zip file together
> with the other modules and run that.

Hmm ... thanks for mentioning this feature, I didn't know of it
before. Sounds great, except that I gather it needs Python >2.5? I'm
stuck with v2.4 at the moment unfortunately...

    J^n
--

-- 
http://mail.python.org/mailman/listinfo/python-list
Permalink | Reply | 0 comments |
headers
Ian | 10 Feb 00:09
Picon
Gravatar

Want to improve my code.

Hi all,

I'm using  lxml etree, and have written a routine to remove nodes in the 
parsed tree.

Typically, I load html, and remove <font> tags, so I am moving the font 
tags children up and moving the text and tail data about.  The code of 
the deleteElem routine is here  http://snipt.org/GSoo0

It troubles me that there is so much repetition in the lines that call 
joiner.

How can I improve the code?

Regards

Ian
Permalink | Reply | 0 comments |
headers
HoneyMonster | 9 Feb 22:57

Re: Apparent "double imports"

On Thu, 09 Feb 2012 15:05:52 -0500, Dave Angel wrote:

> On 02/09/2012 02:40 PM, HoneyMonster wrote:
>> On Thu, 09 Feb 2012 12:02:03 -0700, Ian Kelly wrote:
>>
>>> On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster
>>> <someone <at> someplace.invalid>  wrote:
>>>> One issue I have run into, which may or may not be a problem: I am
>>>> finding that modules in the in-house "library" package sometimes have
>>>> to import modules like sys and os, which are also imported by the
>>>> "calling"
>>>> module. Is this a problem or an overhead, or does it just result in
>>>> two names for the same object?
>>> Two names for the same object.  When a module is imported, the module
>>> object is stored in the sys.modules dict.  Further imports of the same
>>> module just return the same module object from sys.modules.
>> Excellent! It seems it is not a problem at all, then. Thank you.
> Just to add a little subtlety, there is a problem with mutually
> recursive imports.  If module aaa imports module bbb, and modole bbb
> imports aaa, there can be some problems.  Most can be avoided by putting
> the imports right at the beginning of each file, so no work has been
> done before doing the imports.  Then by the time some code tries to use
> them, they're all resolved.  One exception is if you try to import the
> file that is your script file.  This one is made into a module by the
> special name of __main__, and if you import it using the original name,
> you'll have two copies around.  That can lead to some very interesting
> anomalies.
> 
> Better is to make sure no loops exist in the importing tree, which is a
> desirable structuring goal anyway.  When two modules need each other,
(Continue reading)

Permalink | Reply | 0 comments |
headers
SMac2347 | 9 Feb 21:36
Picon

Re: Reading files in from the proper directory

On Feb 7, 3:16 pm, Peter Otten <__pete...@web.de> wrote:
> SMac2...@comcast.net wrote:
> > xls_files   = glob.glob(in_dir + "*.xls")
>
> Try changing that to
>
> pattern = os.path.join(in_dir, "*.xls")
> xls_files = glob.glob(pattern)
>
> os.path.join() inserts a (back)slash between directory and filename if
> necessary.
>
> > merge_xls(in_dir="C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS")
>
> If you paste the directory name literal into the interactive interpreter
> you'll be surprised:
>
> >>> "C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS"
>
> 'C:\\Documents and Settings\\smacdon\\Desktop\x009 Aggregate JWS'
>
> "\09" is intrpreted as chr(9). Use a raw string to prevent Python from
> interpreting a backslash as the start of an escape sequence
>
> >>> r"C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS"
>
> 'C:\\Documents and Settings\\smacdon\\Desktop\\09 Aggregate JWS'
>
> or use forward slashes as directory separators.
(Continue reading)

Permalink | Reply | 0 comments |
headers
SMac2347 | 9 Feb 21:32
Picon

Re: Reading files in from the proper directory

On Feb 7, 3:16 pm, Peter Otten <__pete...@web.de> wrote:
> SMac2...@comcast.net wrote:
> > xls_files   = glob.glob(in_dir + "*.xls")
>
> Try changing that to
>
> pattern = os.path.join(in_dir, "*.xls")
> xls_files = glob.glob(pattern)
>
> os.path.join() inserts a (back)slash between directory and filename if
> necessary.
>
> > merge_xls(in_dir="C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS")
>
> If you paste the directory name literal into the interactive interpreter
> you'll be surprised:
>
> >>> "C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS"
>
> 'C:\\Documents and Settings\\smacdon\\Desktop\x009 Aggregate JWS'
>
> "\09" is intrpreted as chr(9). Use a raw string to prevent Python from
> interpreting a backslash as the start of an escape sequence
>
> >>> r"C:\Documents and Settings\smacdon\Desktop\09 Aggregate JWS"
>
> 'C:\\Documents and Settings\\smacdon\\Desktop\\09 Aggregate JWS'
>
> or use forward slashes as directory separators.
(Continue reading)

Permalink | Reply | 2 comments |
headers
noydb | 9 Feb 21:08
Picon
Gravatar

Formate a number with commas

How do you format a number to print with commas?

Some quick searching, i came up with:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
>>> locale.format('%d', 2348721, True)
'2,348,721'

I'm a perpetual novice, so just looking for better, slicker, more
proper, pythonic ways to do this.

Thanks!
Permalink | Reply | 8 comments |
headers
HoneyMonster | 9 Feb 20:40

Re: Apparent "double imports" (was: Naming convention for in-house modules (Newbie question))

On Thu, 09 Feb 2012 12:02:03 -0700, Ian Kelly wrote:

> On Thu, Feb 9, 2012 at 11:53 AM, HoneyMonster
> <someone <at> someplace.invalid> wrote:
>> One issue I have run into, which may or may not be a problem: I am
>> finding that modules in the in-house "library" package sometimes have
>> to import modules like sys and os, which are also imported by the
>> "calling"
>> module. Is this a problem or an overhead, or does it just result in two
>> names for the same object?
> 
> Two names for the same object.  When a module is imported, the module
> object is stored in the sys.modules dict.  Further imports of the same
> module just return the same module object from sys.modules.

Excellent! It seems it is not a problem at all, then. Thank you.
Permalink | Reply | 1 comment |

Gmane