Re: [Python-Dev] Why does base64 return bytes?
Paul Moore:
> Finding out whether users/projects typically write such a helper
> function for themselves would be a better way of getting this
> information. Personally, I suspect they don't, but facts beat
> speculation.
Well, I did. It was necessary to get 2to3 conversion to work(*). I turned every
occurence of
E.encode('base-64')
and
E.decode('base-64')
into helper function calls that for Python 3 did:
b64encode(E).decode('ascii')
and
b64decode(E.encode('ascii'))
(Or something similar, I don't have the code in front of me.)
Leaving out .decode/.encode('ascii') would simply not have worked. That would
just be asking for TypeError's.
regards, Anders
(*) Yes, I use 2to3, believe it or not. Maintaining Python 2 code and doing an
automated conversion to Python 3 as needed.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] == on object tests identity in 3.x
Chris Angelico wrote: This is off-topic for this thread, but still... The trouble is that your arguably just as wrong is an indistinguishable case. If you don't want two different calculations' NaNs to *ever* compare equal, the only solution is to have all NaNs compare unequal For two NaNs computed differently to compare equal is no worse than 2+2 comparing equal to 1+3. You're comparing values, not their history. You've prompted me to get a rant on the subject off my chest, I just posted an article on NaN comparisons to python-list. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Quick poll: should help() show bound arguments?
Larry Hastings wrote: inspect.signature gets this right: import inspect str(inspect.signature(c.foo)) '(a)' Not always. : Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31) : [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin : Type help, copyright, credits or license for more information. : import inspect : class C1: : ... def f(*args, **kwargs): pass : ... : c = C1() : c.f() : str(inspect.signature(c.f)) : '(**kwargs)' Not to mention: class C2: def g(**kwargs): pass It doesn't really make sense - calling C2().g is guaranteed to fail - but it's legal Python. I'm not saying you can't special-case a few things and fix this, but still, -1/B. I like explicit self. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 457: Syntax For Positional-Only Parameters
Larry Hastings wrote: I look forward to an alternate suggestion. This is the least-bad thing I could come up with. How about a naming convention instead, where using a leading underscore in a parameter name is a hint that it is positional-only. For example, the docstring of sorted: sorted(iterable, key=None, reverse=False) -- new sorted list would become: sorted(_iterable, key=None, reverse=False) -- new sorted list It seems more intuitive than the slash, and requires no change to the toolchain. Although, it may collide slightly with code that uses a leading underscore to indicate implementation detail for a parameter with a default value, but a quick scan of the std. lib. suggests that that's very rare. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as
Hi, offering my DKK 0.50 on the subject. I've used an in-house enum type for the better part of a decade - put up at http://unicollect.dk/download/oss/dc_enum.zip for inspiration. I'm partial to an int subclass, or at least something very int-like, because wrapping C libraries is such a major use case. Enums should support all the operations that C enum's do: indexing, ordering, bitwise math and unnamed values. There's a whole bunch of these wrapped C enum's in the standard library, e.g. in the os, stat and urllib modules. Wouldn't it be good to see them converted to enumeration values, to make them sort-of self-documenting and sort-of typechecked? - About unnamed values: Suppose for example you gather up some stat constants in an enum like this: class S_I(Enum): XOTH = 1 WOTH = 2 ROTH = 4 RWXO = 7 XGRP = 8 WGRP = 16 RGRP = 32 RWXG = 56 XUSR = 64 EXEC = 64 WRITE = 128 WUSR = 128 RUSR = 256 READ = 256 RWXU = 448 SVTX = 512 SGID = 1024 SUID = 2048 FIFO = 4096 FCHR = 8192 FDIR = 16384 FBLK = 24576 FREG = 32768 FLNK = 40960 FSOCK = 49152 Now what happens if you do S_I(5) ? This should not raise an exception: 5 is the perfectly valid combination of XOTH and ROTH. Supporting unnamed values is also useful when reading integer values from an external source - file, network, serial port - where typically you'd first convert the received value to the enum type before doing any processing. If converting to enum type may raise an exception, that would force you to print raw integer values in diagnostics, where you'd rather have printed the userfriendly symbolic names. - The repr of an enum value should be short and sweet. Because sometimes you'll be looking at long lists of information with 2-3 of these on every line, and then EnumValue: Colors.blue [int=3] is just going to be annoyingly verbose. This is how my library eventually printed enums: S_I.ROTH S_I.ROTH S_I(4) S_I.ROTH S_I(5) S_I(5) print(S_I(4)) S_I.ROTH(4) print(S_I(5)) S_I.?(5) - A final thing, attempting to compare or convert values from different enum classes should be a TypeError. E.g. in wxPython, it's easy to mistake wx.OK and wx.ID_OK, and a friendly TypeError message is a good way of detecting this early. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hash collision security issue (now public)
On 1/1/2012 12:28 PM, Christian Heimes wrote: I understood Alexander Klink and Julian Wälde, hash...@alech.de, as saying that they consider that using a random non-zero start value is sufficient to make the hash non-vulnerable. Sufficient against their current attack. But will it last? For a long-running server, there must be plenty of ways information can leak that will help guessing that start value. The alternative, to provide a dict-like datastructure for use with untrusted input, deserves consideration. Perhaps something simpler than a balanced tree would do? How about a dict-like class that is built on a lazily sorted list? Insertions basically just do list.append and set a dirty-flag, and lookups use bisect - sorting first if the dirty-flag is set. It wouldn't be complete dict replacement by any means, mixing insertions and lookups would have terrible performance, but for something like POST parameters it should be good enough. I half expected to find something like that on activestate recipes already, but couldn't find any. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] utf-8 encoding in checkins?
s...@pobox.com wrote: I guess I have my work cut out for me. It appears my preferred mail reader, VM, is not supported out-of-the-box by GNU Emacs (they still use Rmail and Babyl for some reason), and I'm not sure the investment trying to get XEmacs built with MULE is worth the effort. Use a 21.5 beta of XEmacs instead of 21.4, 21.5 deals with utf-8 quite well. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: i18n
Terry Reedy wrote:
Localized messages should be in addition to rather than a replacement
for the English version. I thought we had this discussion somewhere --
here? ideas? maybe a tracker issue?
This could be done as a free-standing library, there's no reason to
involve core CPython. Just do message translation at a later stage,
e.g. in a custom sys.excepthook.
I did a quick demo:
| Python 3.2a1 (r32a1:83346, Jul 31 2010, 18:36:39) [MSC v.1500 32 bit
(Intel)] on
| win32
| Type help, copyright, credits or license for more
information.
| import localise_exceptions
| localise_exceptions.install_excepthook('DK')
| None.no_such_attr
| Traceback (most recent call last):
|
|File stdin, line 1, in module
|
| AttributeError: 'NoneType' objektet har ingen attribut 'no_such_attr'
localise_exceptions.py is at http://pastebin.com/QJCn8gmd
regards, Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3.0, unicode, and os.environ
On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy [EMAIL PROTECTED] wrote: try: files = os.listdir(somedir, errors = strict) except OSError as e: log(verbose error message that includes somedir and e) files = os.listdir(somedir) Instead of a codecs error handler name, how about a callback for converting bytes to str? os.listdir(somedir, decoder=bytes.decode) os.listdir(somedir, decoder=lambda b: b.decode(preferredencoding, errors='xmlcharrefreplace')) os.listdir(somedir, decoder=repr) ISTM that would be simpler and more flexible than going over the codecs registry. One caveat though is that there's no obvious way of telling listdir to skip a name. But if the default behaviour for decoder=None is to skip with a warning, then the need to explicitly ask for files to be skipped would be small. Terry's example would then be: try: files = os.listdir(somedir, decoder=bytes.decode) except UnicodeDecodeError as e: log(verbose error message that includes somedir and e) files = os.listdir(somedir) - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-3.0, unicode, and os.environ
M.-A. Lemburg wrote: Well, this is not too far away from just putting the whole decoding logic into the application directly: files = [filename.decode(filesystemencoding, errors='warnreplace') for filename in os.listdir(dir)] (or os.listdirb() if that's where the discussion is heading) I see what you mean, and yes, I think os.listdirb will do just as well. There is no need for any extra parameters to os.listdir. The typical application will just obliviously use os.listdir(dir) and get the default elide-and-warn behaviour for un-decodable names. That rare special application that needs more control can use os.listdirb and handle decoding itself. Using a global registry of error handlers would just get in the way of an application that needs more control. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] struct module docs vs reality
Gregory P. Smith wrote:
The documentation for the struct module says:
http://docs.python.org/dev/library/struct.html#module-struct
short is 2 bytes; int and long are 4 bytes; long long ( __int64 on
Windows) is 8 bytes
and lists 'l' and 'L' as the pack code for a C long.
As its implemented today, the documentation is incorrect. On an LP64
host (pretty much any 64-bit linux, bsd or unixish thing) a long is 8
bytes.
You overlooked the words Standard size and alignment are as follows
that start the quoted paragraph. It's a little confusing because
standard size is not the default. The default is platform-specific
sizes. Only if you start the format string with , , ! or = do you
get standard sizes.
The reference documentation is correct as it stands, and, I suspect,
so is the LP64 implementation. Doesn't struct.pack('l',42) produce a
4-byte string on LP64?
The tutorial at
http://docs.python.org/tut/node13.html#SECTION001330%3E
has a bug though: the format string should use ''.
I believe zipfile.py correctly uses '' throughout.
regards, Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Three-char file extensions
Scott Dial wrote: In general, this is not true. FAT16 can address a 2GB device and I can think of at least one embedded system I am working with that does not support FAT32. If anything, at least .pyzip reduces to .pyz in 8dot3 (whereas .py.z reduces to .z *yikes!*). However, I think it is still best practice to aim for 8dot3 naming. The three-letter extension namespace is very small and heavily overloaded. There's no such thing as a previously unused three-letter extension; it's bound to conflict with something, even if we don't know what it is. It's not best practice to restrict yourself to short, cryptic, ambiguous names unless you have to. For stuff hardwired into the interpreter, I agree it's safer to stick with 8+3. But this is just the default association created by the installer. If it's creating problems, you can always rename your files to .pyz or whatever you like and create an association for that. I'm a little surprised that people are suffering 8+3 names on their usb drives in this day and age still. I suppose if I had to deal with that, I would just zip/tar up my long-file-named files in an 8+3-named archive. And since a .pyz-file is just such an archive, I concede the point and withdraw my suggestion. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a -z interpreter flag to execute a zip file
Andy C wrote: So does everyone agree that there should be a new extension called .pyz? How about .pyzip instead? To make it more obvious, and not mistakable for .py.z. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
Tim Peters wrote: Do note that this discussion is only about Python 3. Under the view that it was a (minor, but real) design error to /try/ extending Python's integer mod definition to floats, if __mod__, and __divmod__ and __floordiv__ go away for binary floats in P3K they should certainly go away for decimal floats in P3K too. What design error? float.__mod__ works perfectly. -1 % 50 49 -1.0 % 50.0 49.0 It's only Decimal.__mod__ that's inconsistent. float.__mod__ has the usual floating-point inaccuracies, but then with float that goes with the territory. I've had occasion to use it, and it was a pleasant surprise that it just worked, so I didn't have to go to the math module and ponder over the difference between modulo or remainder. float modulo is useful, consistent and intuitive; -1 on removing that. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
Tim Peters wrote: Please read the whole thread. Maybe you did, but you said nothing here that indicated you had. The issues aren't about tiny integers that happen to be in float format, where the result is exactly representable as a float too. Those don't create problems for any definition of mod. But even non-tiny exact integers can. I did read the whole thread, and I saw your -1%1e100 example. Mixing floating-point numbers of very different magnitude can get you in trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that worse. It's only Decimal.__mod__ that's inconsistent. float.__mod__ has the usual floating-point inaccuracies, but then with float that goes with the territory. No. Decimal.__mod_ always returns the mathematically exact result. I meant inconsistent with integers. People are familiar with the semantics of % on integers, because they use it all the time. % on float is a natural extension of that and hence unsurprising. % on Decimal is exact and correct, but surprising all the same. regards, Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Floor division
[Tim Peters] [Anders J. Munch] I did read the whole thread, and I saw your -1%1e100 example. Mixing floating-point numbers of very different magnitude can get you in trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that worse. Except that it's very easy to return an exactly correct result in that case: -1. Except that the function that computes -1 is a different function. Either it makes a difference which function is computed or it doesn't: If it makes a difference, because the first operand may be negative, then the programmer absolutely has to choose the correct function, or the program will have a bug. If the correct function is one whose result cannot be exactly represented, then there's nothing that can be done about that. Whether the function is called using a % infix operator or using math.untrustworthy_intlike_fmod doesn't change the fact that the result is going to be inexact. If it doesn't make a difference, because the first operand is always positive, then both functions provide exactly representable results. So regardless, the current float.__mod__ doesn't create inexact results where exact results are possible. Suppose for example I'm normalising radians to the [0; 2*math.pi] range using radians %= 2*math.pi Changing that to radians = math.fmod(radians, 2*math.pi) would simply be incorrect. I could of course rewrite that to give the correct result with a conditional and a bit more calculation, still using math.fmod, but then the inexactness would reappear. It was natural to /want/ to extend it to floats. That didn't work well, and to the contrary it's surprising precisely /because/ the behavior people enjoy with integers can fail when it's applied to floats. What makes you say it didn't work well? What user experiences do you base that on? - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposed changes to PEP 343
Nick Coghlan did a +1 job to write: 1. Amend the statement specification such that: with EXPR as VAR: BLOCK is translated as: abc = (EXPR).__with__() exc = (None, None, None) VAR = abc.__enter__() try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) Note that __with__ and __enter__ could be combined into one with no loss of functionality: abc,VAR = (EXPR).__with__() exc = (None, None, None) try: try: BLOCK except: exc = sys.exc_info() raise finally: abc.__exit__(*exc) - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
Walter Dörwald wrote: We should have one uniform way of representing time in Python. IMHO datetime objects are the natural choice. Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
I wrote: Alas datetime objects do not unambiguously identify a point in time. datetime objects are not timestamps: They represent the related but different concept of _local time_, which can be good for presentation, but shouldn't be allowed anywhere near a persistent store. GvR replied: You misunderstand the datetime module! You can have a datetime object whose timezone is UTC; or you can have a convention in your API that datetime objects without timezone represent UTC. I can do a lot of things in my own code, and I'm sure the datetime module provides tools that I can build on to do so, but that doesn't help in interfacing with other people's code -- such as the standard library. Try saving a pickle of datetime.now() and reading it on a computer set to a different time zone. The repr will then show the local time on the _originating_ computer, and figuring out the absolute time this corresponds to requires knowledge of time zone and DST settings on the originating computer. How about datetime.utcnow(), then? Just use UTC for datetime timestamps? But that goes against the grain of the datetime module: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import datetime, time datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.now() datetime.timedelta(0) datetime.datetime.fromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0, 7200) It seems when I subtract the present time from the present time, there's a two hour difference. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding the 'path' module (was Re: Some RFE forreview)
From: Guido van Rossum [mailto:[EMAIL PROTECTED] datetime.datetime.utcfromtimestamp(time.time()) - datetime.datetime.utcnow() datetime.timedelta(0) I overlooked the utcfromtimestamp method, sorry. Your bug is similar to comparing centimeters to inches, or speed to acceleration, or any number of similar mistakes. Quite so, and that is exactly the point. time.time() unambiguously identifies a point in time. A datetime object does not. At least not unless a tzinfo object is included, and even then there is a corner case at the end of DST that cannot possibly be handled. If ctime/mtime/atime were to return datetime objects, that would pretty much have to be UTC to not lose information in the DST transition. I doubt that's what Walter wanted though, as that would leave users with the job of converting from UTC datetime to local datetime; - unless perhaps I've overlooked a convenient UTC-local conversion method? - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 343 - Abstract Block Redux
Shane Hathaway wrote: Guido van Rossum wrote: Consider an application where you have to acquire *two* locks regularly: You really have to write it like this: Shane, you've already solved this one more elegantly: def lockBoth(): return combining(lock1.locking(), lock2.locking()) using the combining function you wrote earlier, which I assume will make it into the library. - Anders ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 340: Else clause for block statements
GvR wrote:
[Nick Coghlan]
Option 2: mimic if semantics
An 'else' clause on a block statement behaves vaguely like the else
clause on
an if statement - the clause is executed only if the first suite is
never
entered, but no exception occurs (i.e. StopIteration is raised by the
first call
to next).
Strange because it's different from the behavior of a for loop, and
the block-statement doesn't feel like an if-statement at all. But I
could actually imagine a use case: when acquiring a lock with a
time-out, the else-clause could be executed when the acquisition times
out.
block locking(myLock, timeout=30):
...code executed with lock held...
else:
...code executed if lock not acquired...
A file-closing block function has the same need, as does any block
function that manages a resource, whose acquisition might fail.
A surrounding try/except doesn't quite cut it; the problem is that the
try-clause will then also cover the suite.
Example:
try:
in opening('file1') as f1:
...
in opening('file2') as f2:
...
except IOError:
print file1 not available, I'll try again later
How do I tell try/except that I really only meant to trap
opening('file1'), but opening 'file2' is not supposed to fail so I
want any exception from that propagated? Better if I could write:
in opening('file1') as f1:
...
in opening('file2') as f2:
...
else:
print file1 not available, I'll try again later
or even
in opening('file1') as f1:
...
in opening('file2') as f2:
...
except IOError:
print file1 not available, I'll try again later
I rather like this version, because it is patently clear what should
happen if there is no except-clause: The exception propagates
normally.
- Anders
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
