Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform

[Eric Smith]

We need a really long lead time before we can remove these. I
recommend starting with a *silent* deprecation in 3.1 combined with a
PR offensive for the new names.


I think the old names basically have to live forever in some way, due to 
loading old pickles. Remember the problems we had when we tried to 
restructure the library in 2.6?


___
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] Ext4 data loss

[Eric Smith]

Antoine Pitrou wrote:

I think your "synced" flag is too vague. Some applications may need the file to
be synced on close(), but some others may need it to be synced at regular
intervals, or after each write(), etc.


Why wouldn't sync just be an optional argument to close(), at least for 
the "sync_on_close" case?


Eric.
___
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] Ext4 data loss

[Eric Smith]

Antoine Pitrou wrote:

Eric Smith  trueblade.com> writes:
Why wouldn't sync just be an optional argument to close(), at least for 
the "sync_on_close" case?


It wouldn't work with the "with" statement.



Well, that is a good reason, then!
___
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

[Python-Dev] Can I modify string.Formatter._vformat?

[Eric Smith]

I'm implementing support for auto-numbering of str.format() fields (see 
http://bugs.python.org/issue5237). I'm reasonably sure that when I'm 
done modifying the C implementation I'll need to change the signatures 
of string.Formatter._vformat, str._formatter_parser, and/or 
str._formatter_field_name_split. (They need to support the state needed 
to track the auto-number field counter.)


I've always considered these internal implementation details of 
str.format and string.Formatter. They begin with underscores and are not 
documented.


Is there any problem with modifying these in 2.7 and 3.1? I assume not, 
but I want to make sure it doesn't give anyone heartburn.


Eric.
___
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-ideas] Rough draft: Proposed format specifier for a thousands separator (discussion moved from python-dev)

[Eric Smith]

Raymond Hettinger wrote:

Eric Smith pointed-out that these are already
handled by the "n" specifier in the locale module (albiet only
for integers).


It's supported by float, but it's just not very useful. For Decimal it's
unsupported. Maybe this isn't a distinction worth pointing out.


Proposal I (from Nick Coghlan)
==

...

[[fill]align][sign][#][0][width][,][.precision][type]



Proposal II (to meet Antoine Pitrou's request)
==

...

[[fill]align][sign][#][0][width][T[tsep]][dsep precision][type]


I was going to suggest that since the locale name for this is 
"grouping", we use "G". But since we're not doing a general-purpose 
grouping implementation, I think "T" better says "we're doing thousands, 
not general grouping. Perhaps this should go in a rationale section if 
we opt for "T". Now that I think about it, "G" is already a valid type, 
so it wouldn't work, anyway.



 format(1234, "8T,d")--> '   1,234'


For proposal 2, this case is unfortunate. Because for integers, there is
no decimal allowed in the mini-language (it's currently illegal to use
"8.1d"), you'd only ever add the thousands, but you'd always need the
"T". It would be nice to come up with a specification that would degrade
for integers such that "8,d" would give '   1,234'. Proposal 1 is much
nicer in that regard, although I definitely like the fact that the
actual characters used for DOT and COMMA can be specified with proposal 2.

Maybe you'd never really use "T,", since the comma is redundant, and 
you'd say:

 format(1234, "8Td")--> '   1,234'
in normal use. But "d" is also the default, so it just becomes:
 format(1234, "8T") --> '   1,234'

I like approach 2 in general. I'll give some thought to other, similar 
schemes which would allow "8," or "8,d" to work. I think people will 
write "8," and expect "   1,234", not an error.


Eric.
___
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] "setuptools has divided the Python community"

[Eric Smith]

P.J. Eby wrote:
> As someone else suggested, moving some of the functionality to PEP 302
> interfaces would also help.  Most of the code, though, deals with
> locating/inspecting installed distributions, resolving version
> requirements, and managing sys.path.  And most of the nastiest
> complexity comes from trying to support true filename access to
> resources -- if that were dropped from the stdlib, there'd be no need
> for egg caches and the like, along with all the complexity entailed.
>
> Application environments such as Chandler, Trac, Zope, etc. that want
> their plugins to live in .egg files wouldn't necessarily be able to use
> such an API, but the independent pkg_resources wouldn't be
> disappearing.  (Of course, they could also implement
> application-specific file extraction, if the stdlib API included the
> ability to inspect and open zipped resources.)

Could you comment on why they couldn't use such an API?

___
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] version compare function into main lib

[Eric Smith]

anatoly techtonik wrote:

Correct me if I wrong, but shouldn't Python include function for
version comparisons?





What do you think about adding cmpversions(first, second,
strict=false) based on distutils into main lib?


distutils _is_ already in the "main lib", that is, the standard library.


Will it be more appropriate to isolate the function into "versions" module?
Should it be rewritten to remove re dependency in this case?


Given that re is also in the standard library, and this is hardly speed
critical, I'd say no.


Distutils version comparisons:
http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/version.py?view=markup


I don't see the point of moving this, unless it's part of some larger,
radical "fix distutils" effort. And even then I'm not convinced.

This probably belongs on the python-ideas mailing list, or on the
distutils SIG list. I expect you'll see a lot of discussion on distutils
SIG list in the coming days.

Eric.


___
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] "setuptools has divided the Python community"

[Eric Smith]

M.-A. Lemburg wrote:

On 2009-03-27 04:19, Guido van Rossum wrote:

- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete


Should this be read as:

- remove bdist_rpm from the stdlib and let it live on PyPI

?


As one of the people who proposed this, I think it means: move 
bdist_rpm, bdist_msi, etc. out of distutils, but provide some of them 
with the standard Python installation. I'm certain that as part of the 
refactoring and simplification of distutils we'll gradually move the 
existing bdist_* commands into separate, stand-alone "things" (scripts, 
callable modules, or something). We'll need to do this if only for 
testing, so we may as well make them work.



Instead of removing such functionality, I think we should add
more support for standard packaging formats to distutils, e.g.
bdist_deb, bdist_pkg, etc.


Agreed.


And for eggs, there should be a standard bdist_egg, written against
the core distutils APIs (*), creating archives which other Python
package managers can then use in whatever way they seem fit.


Agreed.


Just please don't tie eggs to one specific package manager,
e.g. having to install setuptools just to run eggified packages
is just plain wrong. The format itself doesn't require this and
neither should the software shipped with those eggs.


I think that whatever we produce will need to be supported by the 
standalone version of the installer portion that will be backported and 
separately available.

___
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] "setuptools has divided the Python community"

[Eric Smith]

Olemis Lang wrote:

On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore  wrote:

2009/3/27 Guido van Rossum :

- keep distutils, but start deprecating certain higher-level
functionality in it (e.g. bdist_rpm)
- don't try to provide higher-level functionality in the stdlib, but
instead let third party tools built on top of these core APIs compete

Please don't move bdist_wininst out of the core, though!

I'd argue that Windows is a special case, as many Windows users don't
have the ability to build their own extensions,


H ... what about devs (me?) trying to build installers for
multiple platforms being in a single OS (let's say Ubuntu ...) ? IMO
in this case where policies are unique for a particular OS-flavour
(deb, rpms, and so on ...) ... there should be a single way to package
your app and to conform to the standards agreed by distros (e.g.
Debian) and maintainers ... isnt it enough std to be in stdlib ? I'd
really like to have those (... at least the most influential systems
... rpm, debs, and maybe two or three more that I'm missing here ...)


The idea is to make the metadata extensible, so that for example Debian 
specific information can be put in the same config file that contains 
the "normal" metadata. I guess it would even be possible for this 
additional metadata to be in a separate config file. That way if someone 
downstream from me says "I can automatically build a .deb file if you'd 
just include this metadata", I could easily do that. I don't think it's 
reasonable that a package builder could possibly know all of the config 
information. To some extent, this is all currently possible with 
setup.cfg, and I do that myself.


I'm also not convinced there will be a single "bdist_rpm" (or whatever) 
replacement. It's entirely possible that different people would want to 
build different flavors of rpm's from the same metadata. Someone might 
be a real FHS devotee, and someone else might have practical reasons to 
not follow it.



Indeed I'd like to know the arguments behind «deprecating certain
higher-level functionality in it (e.g. bdist_rpm)» BTW ... perhaps
they'r self-explanatory and therefore I should not be asking this at
all ... :P


I believe it's largely a refactoring. It's just too complicated and 
difficult to extend the way it is now.


Eric.

___
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] version compare function into main lib

[Eric Smith]

Martin v. Löwis wrote:

Correct me if I wrong, but shouldn't Python include function for
version comparisons?


On the packaging summit yesterday, people agreed that yes, we should
have something like that in the standard library, and it should be more
powerful than what distutils currently offers.


Yes.


There was no conclusion of how specifically that functionality should
be offered; several people agreed that Python should mandate a standard
format, which it is then able to compare. So you might not be able to
spell it "10.3.40-beta", but perhaps "10.3.40b1" or "10.3.40~beta".


I got the impression that people are generally happy with what 
setuptools provides for version parsing and comparison.


Does anyone think that's not a good model?

Eric.
___
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] version compare function into main lib

[Eric Smith]

Mart Sõmermaa wrote:


Instead of trying to parse some version string, distutils should
require defining the version as tuple with well-defined entries -
much like what we have in sys.version_info for Python.

The developer can then still use whatever string format s/he wants.

The version compare function would then work on this version tuple
and probably be called cmp() (at least in Python 2.x ;-).



Except there need to be functions for parsing the tuple from a string 
and preferably a canonical string representation to ease that parsing. 
Hence the Version class in "Version Handling" referred to above.


Right. For example, say you need to specify in a config file that your 
package requires version 1.3.4 of some other tool. I think the only 
rational way to do this is in a string, and be able to parse the version 
number (possibly into a tuple) and compare it with other version 
numbers. I don't think you want to directly specify the tuple in such a 
case.


Eric.

___
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] "setuptools has divided the Python community"

[Eric Smith]

M.-A. Lemburg wrote:

On 2009-03-27 17:07, P.J. Eby wrote:

At 11:37 PM 3/26/2009 -0500, Eric Smith wrote:

P.J. Eby wrote:

As someone else suggested, moving some of the functionality to PEP 302
interfaces would also help.  Most of the code, though, deals with
locating/inspecting installed distributions, resolving version
requirements, and managing sys.path.  And most of the nastiest
complexity comes from trying to support true filename access to
resources -- if that were dropped from the stdlib, there'd be no need
for egg caches and the like, along with all the complexity entailed.

Application environments such as Chandler, Trac, Zope, etc. that want
their plugins to live in .egg files wouldn't necessarily be able to use
such an API, but the independent pkg_resources wouldn't be
disappearing.  (Of course, they could also implement
application-specific file extraction, if the stdlib API included the
ability to inspect and open zipped resources.)

Could you comment on why they couldn't use such an API?

If a plugin includes C code (.so/.dll), or uses a library that operates
on filenames rather than bytes in memory (e.g. gettext), then the
resources would need to be extracted from the .egg.  pkg_resources
transparently extracts such resources to a cache directory when you ask
for a resource's filename, rather than asking for a stream or string of
its contents.

This feature represents a significant chunk of the complexity and code
size of pkg_resources -- and I was proposing ways to cut down on that
complexity and code size, for a (limited) stdlib version of the
functionality.


This functionality is one of the more annoying setuptools
"features". It causes each and every user of e.g. Trac to have
their own little version of the same piece of software in their
home dir cache.

The solution to this is simple: don't use ZIP files for installed
packages, instead unzip them into normal directories on sys.path.

This makes all these problems go away and allows users to access
embedded documentation, configuration, etc.

Zip files are great for shipping packages to the end-user, but
there's no need to keep them zipped once they get there.



I also think the feature should go. If you want functionality that's so 
difficult to provide when you install as a zip file, the answer is not 
to make things more complex, but to not install as zip files.


___
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] "setuptools has divided the Python community"

[Eric Smith]

Olemis Lang wrote:

I also think the feature should go. If you want functionality that's so
difficult to provide when you install as a zip file, the answer is not to
make things more complex, but to not install as zip files.



What about environments like Google App Engine ? I mean, AFAIK using
ZIP files is the *official* solution to meet some quotas &
requirements ... CMIIW anyway ...

I mean, for example: what if someone writes an app containing
resources like message catalogs for i18n, uploads it to GAE using ZIP
files and still wants to use the MO files (i.e. resources) for
translation (i.e. for anything else ...) ... H ?


I mentioned yesterday (in the language summit) that we really need to 
get all the requirements together before we start any work. I fear that 
there are many hidden requirements (or ones that I'm personally not 
aware of, at least). I don't know gettext well enough give an answer yet.



___
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] version compare function into main lib

[Eric Smith]

Martin v. Löwis wrote:


I got the impression that people are generally happy with what 
setuptools provides for version parsing and comparison.


Does anyone think that's not a good model?


Procedurally, I think it's a very bad approach. I don't mind
the setuptools implementation being used as a basis (assuming
it gets contributed), but *independently* I think a specfication
is needed what version strings it actually understands. Such
specification must precede the actual implementation (in distutils).


Agreed. Specifications first, for all of this work.
___
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] splitting out bdist_*

[Eric Smith]

Martin v. Löwis wrote:
I do think that it's relevant that the respective operating system 
packagers don't find bdist_rpm, bdist_deb, et. al. useful.  It's not 
very useful to have a bdist_deb that nobody actually builds debs with. 


I think that conclusion is invalid: just because the distributions don't
use it doesn't mean that nobody uses it. As a data point, there are 16
packages on PyPI that release RPMs (I haven't checked how
they actually built them, though).


And I personally use bdist_rpm for my work, which I distribute to a farm 
of servers under my control. So no doubt it's used.



In fact, .deb is a proof that it does *not* help to have the package
commands outside distutils. For .deb, the command actually *is* outside
distutils (there is no bdist_deb in distutils) - and it hasn't helped.


It proves that it doesn't help given the current state of affairs. I 
suspect that if all of this additional information needed to build a 
.deb (for example) could be included as metadata in the python package 
(using the word "package" loosely), that it would be. It would make the 
ultimate packager's life easier, and it's no real burden for the 
original author.


___
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] Version strings

[Eric Smith]

Martin v. Löwis wrote:

I just collected the version strings of versions that
got released to PyPI, and put up the list on

http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions


That's excellent, thank you.

The following chunk of text is present. I don't really care, except that 
it might mean a bug in your extraction routine. Or maybe it's just a 
very wacky version string!



Sysv_ipc gives Python programs access to System V semaphores, shared memory
 and message queues. Most (all?) Unixes (including OS X) support System 
V IPC.

 Windows+Cygwin 1.7 might also work.

 Sample code is included.

 This extension is released under the GPL.

 You might also be interested in the similar POSIX IPC module at:
 http://semanchuk.com/philip/posix_ipc/
 T-0.3.4 (BitTornado)
 Trunk

___
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] splitting out bdist_*

[Eric Smith]

Stephen J. Turnbull wrote:

Eric Smith writes:

 > And I personally use bdist_rpm for my work, which I distribute to a farm 
 > of servers under my control. So no doubt it's used.


Sure, but use for internal distribution is very different from to
problem its being asked to solve now, isn't it?  IIUC, you're
basically using RPM as an installer for a standalone application,
where you set policy at both ends, packaging and installation.  This
may be a group of modules which may have internal interdependencies,
but very likely the environment doesn't change much.  Pretty much
anything will do in that kind of situation, and I don't think it would
matter to you if there are zero, one, or twelve such tools in stdlib,
as long as there's one you like in PyPI somewhere.


I was just pointing out that bdist_rpm has users, and it's not likely to 
be abandoned. It's certainly true that different users have different 
use cases for it.


It's this lack of understanding of all the use cases that most concerns 
me about this overall effort. How can we know if we succeeded if we 
don't all agree on the state we're trying to get to?


To be concrete, I think distutils should support (among other things):
- entry points for plugins
- entry points as used for producing console and windowed "scripts"
- dependency declarations for other python packages
- dependency declarations for non-python packages

But maybe these goals aren't shared by others, and don't fall into 
anyone else's "make distutils better" concept.


PJE pointed out "A library that targets Python 2.4 and 2.5 and uses 
wsgiref, sqlite, ctypes, or ElementTree, for example, may have different 
dependencies depending on the version it is being installed in." Is that 
something we want to support?



 > [That .deb tools are necessarily maintained outside of bdist]
 > proves that [external maintenance] doesn't help given the current
 > state of affairs. I suspect that if all of this additional
 > information needed to build a .deb (for example) could be included
 > as metadata in the python package (using the word "package"
 > loosely), that it would be. It would make the ultimate packager's
 > life easier, and it's no real burden for the original author.

I'm not sure what you mean by "it would be".  Are you referring to
what I believe to be true, that because Python and Python-based apps
need to integrate with the rest of the OS, it's quite burdensome for
module authors to include the necessary information, which is likely
to vary from packaging tool to packaging tool, and according to policy
even among packagers using the same tool?  Or do you mean that it
would be useful, so it would be nice if such information were
included, and that as you see it the required effort would be small?


I don't see how they differ. It's definitely true that packagers using 
the same tool might want to produce different package layouts and no 
doubt other differences. I don't see why it wouldn't be easy to have 
these differences driven by different policies acting on the same 
metadata, or small amounts of custom (per-packager) metadata.

___
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] CPython and C++ object GC

[Eric Smith]

Nick Coghlan wrote:

Csaba Balazs wrote:

Hello Everybody,

I would like to use a C++ gui library with the following (simplified) interface
in Python.


This is a question for python-list/comp.lang.python (i.e. development
*using* Python, including the C API), not python-dev (which is for
development of the language itself).


There's also the capi-sig mailing list, 
http://mail.python.org/mailman/listinfo/capi-sig.


___
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] Test failures under Windows?

[Eric Smith]

Kristján Valur Jónsson wrote:

Btw, I am working on finding out the test suite failures for 
test_multiprocessing.


Some of those are caused by force builds on a branch, so make sure the 
errors are still occurring before you put too much effort into this. We 
made the branch before some recent fixes to the py3k branch.


But of course there may still be errors that exist.

Eric.

___
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 382: Namespace Packages

[Eric Smith]

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Apr 6, 2009, at 9:21 AM, Jesse Noller wrote:
>
>> On Thu, Apr 2, 2009 at 4:33 PM, M.-A. Lemburg  wrote:
>>> On 2009-04-02 17:32, Martin v. Löwis wrote:
 I propose the following PEP for inclusion to Python 3.1.
>>>
>>> Thanks for picking this up.
>>>
>>> I'd like to extend the proposal to Python 2.7 and later.
>>>
>>
>> -1 to adding it to the 2.x series. There was much discussion around
>> adding features to 2.x *and* 3.0, and the consensus seemed to *not*
>> add new features to 2.x and use those new features as carrots to help
>> lead people into 3.0.
>
> Actually, isn't the policy just that nothing can go into 2.7 that
> isn't backported from 3.1?  Whether the actual backport happens or not
> is up to the developer though.  OTOH, we talked about a lot of things
> and my recollection is probably fuzzy.

I believe Barry is correct. The official policy is "no features in 2.7
that aren't also in 3.1". I personally think I'm not going to put anything
else in 2.7, specifically the ',' formatter stuff from PEP 378. 3.1 has
diverged too far from 2.7 in this regard to make the backport easy to do.
But this decision is left up to the individual committer.

___
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] Shorter float repr in Python 3.1?

[Eric Smith]

Mark Dickinson wrote:

One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.

Any thoughts/objections/counter-proposals/...?


As part of the decision process, we've tried this on several buildbots, 
and it has been successful on at least:


AMD64 Gentoo:
http://www.python.org/dev/buildbot/3.x/amd64%20gentoo%203.x/builds/592

PPC Debian unstable:
http://www.python.org/dev/buildbot/3.x/ppc%20Debian%20unstable%203.x/builds/584

Sparc Solaris 10:
http://www.python.org/dev/buildbot/3.x/sparc%20solaris10%20gcc%203.x/builds/493 



The Sparc test failed, but that wasn't our fault! Our tests succeeded.

These builds are in addition to x86 Linux and x86 Mac, which we've 
developed on.



Eric.
___
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

[Python-Dev] Deprecating PyOS_ascii_formatd

[Eric Smith]

Assuming that Mark's and my changes in the py3k-short-float-repr branch 
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its 
functionality is largely being replaced by PyOS_double_to_string, which 
we're introducing on our branch.


PyOS_ascii_formatd was introduced to fix the issue in PEP 331. 
PyOS_double_to_string addresses all of the same issues, namely a 
non-locale aware double-to-string conversion. PyOS_ascii_formatd has an 
unfortunate interface. It accepts a printf-like format string for a 
single double parameter. It must parse the format string into the 
parameters it uses. All uses of it inside Python already know the 
parameters and must build up a format string using sprintf, only to turn 
around and have PyOS_ascii_formatd reparse it.


In the branch I've replaced all of the internal calls to 
PyOS_ascii_format with PyOS_double_to_string.


My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2.

The 2.7 situation is tricker, because we're not planning on backporting 
the short-float-repr work back to 2.7. In 2.7 I guess we'll leave 
PyOS_ascii_formatd around, unfortunately.


FWIW, I didn't find any external callers of it using Google code search.

And as a reminder, the py3k-short-float-repr changes are on Rietveld at 
http://codereview.appspot.com/33084/show. So far, no comments.

___
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] Deprecating PyOS_ascii_formatd

[Eric Smith]

Nick Coghlan wrote:

Eric Smith wrote:

And as a reminder, the py3k-short-float-repr changes are on Rietveld at
http://codereview.appspot.com/33084/show. So far, no comments.



Looks like you were able to delete some fairly respectable chunks of
redundant code!


Wait until you see how much nasty code gets deleted when I can actually 
remove PyOS_ascii_formatd!


And thanks for your comments on Rietveld, especially catching the memory 
leak.


Eric.

___
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] Shorter float repr in Python 3.1?

[Eric Smith]

Mark has uploaded our newest work to Rietveld, again at 
http://codereview.appspot.com/33084/show. Since the last version, Mark 
has added 387 support (and other fixes) and I've added localized 
formatting ('n') back in as well as ',' formatting for float and int. I 
think this addresses all open issues. If you have time, please review 
the code on Rietveld.


We believe we're ready to merge this back into the py3k branch. Pending 
any comments here or on Rietveld, we'll do the merge in the next day or so.


Before then, if anyone could build and test the py3k-short-float-repr 
branch on any of the following machines, that would be great:


Windows (preferably 64-bit)
Itanium
Old Intel/Linux (e.g., the snakebite nitrogen box)
Something bigendian, like a G4 Mac

We're pretty well tested on x86 Mac and Linux, and I've run it once on 
my Windows 32-bit machine.


I have a Snakebite account, and I'll try running on nitrogen once I 
figure out how to log in again.


I just had Itanium and PPC buildbots test our branch, and they both 
succeeded (or at least failed with errors not related to our changes).


Eric.

___
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] Shorter float repr in Python 3.1?

[Eric Smith]

Benjamin Peterson wrote:

Cool. Will you use svnmerge.py to integrate the branch? After having
some odd behavior merging the io-c branch, suggest you just apply a
patch to the py3k branch,


We're just going to apply 2 patches, without using svnmerge. First we'll 
add new files and the configure changes. Once we're sure that builds 
everywhere, then the second step will actually hook in the new functions 
and will have the formatting changes.

___
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] Shorter float repr in Python 3.1?

[Eric Smith]

Ned Deily wrote:

In article <49e3d34e.8040...@trueblade.com>,
 Eric Smith  wrote:
Before then, if anyone could build and test the py3k-short-float-repr 
branch on any of the following machines, that would be great:



[...]

Something bigendian, like a G4 Mac


I'll crank up some OS X installer builds and run them on G3 and G4 Macs 
vs 32-/64- Intel.  Any tests of interest beyond the default regttest.py?


Thanks! regrtest.py should be enough.

Eric.
___
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] Shorter float repr in Python 3.1?

[Eric Smith]

Ned Deily wrote:
I'll crank up some OS X installer builds and run them on G3 and G4 Macs 
vs 32-/64- Intel.  Any tests of interest beyond the default regttest.py?


FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 
10.3 and above; this is the similar to recent python.org OSX installers.  
The good news: on 10.5 i386, running the default regrtest, no signficant 
differences were noted from an installer built from the current main 
py3k head.


Okay, that's awesome. Thanks.

Bad news: the same build installed on a G4 running 10.5 hung hard in 
test_pow of test_builtin; a kill was needed to terminate python.  Same 
results on a G3 running 10.4. 


Okay, that's less than awesome. But still a huge thanks.


Then I tried a couple of random floats:

Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) 
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin

Type "help", "copyright", "credits" or "license" for more information.

3.1

-9.255965342383856e+61

1.

^C
Terminated  <-- kill needed


I don't suppose it's possible that you could run this under gdb and get 
a stack trace when it starts looping (assuming that's what's happening)?


I think I might have a PPC Mac Mini I can get my hands on, and I'll test 
there if possible.


Eric.

___
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] Issue5434: datetime.monthdelta

[Eric Smith]

Jess Austin wrote:

What other behavior options besides "last-valid-day-of-the-month"
would you like to see?


- Add 30 days to the source date.
I'm sure there are others.

Followups to python-ideas.

___
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] 3.1 beta blockers

[Eric Smith]

Alessio Giovanni Baroni wrote:
There are some cases of OutOfMemory? On my machine the float->string 
conversion is all ok. Also 'make test' is all ok.


I assume you're talking about issue 5775. I think it's all explained in 
the bug report. Basically, the float->string conversion can now return 
an out of memory error, which it could not before. marshal.c's w_object 
doesn't check for those error conditions. I doubt they'll ever occur in 
any test, but they need to be handled none the less.


It's on my list of things to do in the next week. But if there's anyone 
who understands the code and would like to take a look, feel free.


Eric.



2009/4/21 Benjamin Peterson >


The first (and only) beta of 3.1 is scheduled for less than 2 weeks
away, May 2nd, and is creeping onto the horizon. There are currently 6
blockers:

#5692: test_zipfile fails under Windows - This looks like a fairly
easy fix.

#5775: marshal.c needs to be checked for out of memory errors - Looks
like Eric has this one.

#5410: msvcrt bytes cleanup - It would be nice to have a Windows
expert examine the patch on this issue for correctness.

#5786: [This isn't applicable to 3.1]

#5783: IDLE cannot find windows chm file - Awaiting a fix to the IDLE
or the doc build system.


--
Thanks for your work,
Benjamin
___
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/alessiogiovanni.baroni%40gmail.com





___
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/eric%2Bpython-dev%40trueblade.com


___
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] 3.1 beta blockers

[Eric Smith]

Eric Smith wrote:

Alessio Giovanni Baroni wrote:
There are some cases of OutOfMemory? On my machine the float->string 
conversion is all ok. Also 'make test' is all ok.


I assume you're talking about issue 5775. I think it's all explained in 
the bug report. Basically, the float->string conversion can now return 
an out of memory error, which it could not before. marshal.c's w_object 
doesn't check for those error conditions. I doubt they'll ever occur in 
any test, but they need to be handled none the less.


It's on my list of things to do in the next week. But if there's anyone 
who understands the code and would like to take a look, feel free.


I just fixed it in r71783, so it should be off the list of release blockers.
___
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] Summary of Python tracker Issues

[Eric Smith]

Mark Dickinson wrote:

On Fri, Apr 24, 2009 at 9:25 PM, Terry Reedy  wrote:

In going through this, I notice a lot of effort by Mark Dickenson and others


Many others, but Eric Smith's name needs to be in big lights here.
There's no way the short float repr would have been ready for 3.1 if
Eric hadn't shown an interest in this at PyCon, and then taken on
the major internal replumbing job this entailed for all of Python's
string formatting.


Not to get too much into a mutual admiration mode, but Mark did the 
parts involving hard thinking.



3.1.  As a certain-to-be beneficiary, I want to thank all who contributed.


Glad you like it!


Me, too. I think it's going to be great once we get it all straightened 
out. And I think we're close!


Eric.

___
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] Deprecating PyOS_ascii_formatd

[Eric Smith]

Eric Smith wrote:
Assuming that Mark's and my changes in the py3k-short-float-repr branch 
get checked in shortly, I'd like to deprecate PyOS_ascii_formatd. Its 
functionality is largely being replaced by PyOS_double_to_string, which 
we're introducing on our branch.


We've checked the changes in, and everything looks good as far as I can 
tell.



My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in 3.2.


Having heard no dissent, I'd like to go ahead and deprecate this API. 
What are the mechanics of deprecating this? Just documentation, or is 
there something I should do in the code to generate a warning? Any 
pointers to examples would be great.


The 2.7 situation is tricker, because we're not planning on backporting 
the short-float-repr work back to 2.7. In 2.7 I guess we'll leave 
PyOS_ascii_formatd around, unfortunately.


I backported the new API to 2.7, so I'll also deprecate 
PyOS_ascii_formatd there.


Eric.

___
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] Deprecating PyOS_ascii_formatd

[Eric Smith]

Benjamin Peterson wrote:

2009/4/24 Eric Smith :

My proposal is to deprecate PyOS_ascii_formatd in 3.1 and remove it in
3.2.

Having heard no dissent, I'd like to go ahead and deprecate this API. What
are the mechanics of deprecating this? Just documentation, or is there
something I should do in the code to generate a warning? Any pointers to
examples would be great.


You can use PyErr_WarnEx().


Thanks. I created issue 5835 to track this. I marked it as a release 
blocker, but I should have no problem finishing it up this weekend.

___
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-checkins] r71946 - peps/trunk/pep-0315.txt

[Eric Smith]

You might want to note in the PEP that the problem that's being solved 
is known as the "loop and a half" problem.


http://www.cs.duke.edu/~ola/patterns/plopd/loops.html#loop-and-a-half

raymond.hettinger wrote:

Author: raymond.hettinger
Date: Sun Apr 26 02:34:36 2009
New Revision: 71946

Log:
Revive PEP 315.

Modified:
   peps/trunk/pep-0315.txt

Modified: peps/trunk/pep-0315.txt
==
--- peps/trunk/pep-0315.txt (original)
+++ peps/trunk/pep-0315.txt Sun Apr 26 02:34:36 2009
@@ -2,9 +2,9 @@
 Title: Enhanced While Loop
 Version: $Revision$
 Last-Modified: $Date$
-Author: W Isaac Carroll 
-Raymond Hettinger 
-Status: Deferred
+Author: Raymond Hettinger 
+W Isaac Carroll 
+Status: Draft
 Type: Standards Track
 Content-Type: text/plain
 Created: 25-Apr-2003
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins



___
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] Two proposed changes to float formatting

[Eric Smith]

Mark Dickinson wrote:

I'd like to propose two minor changes to float and complex
formatting, for 3.1.  I don't think either change should prove
particularly disruptive.

(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50.  For example:

...

I propose removing this feature for 3.1


I'm +1 on this.


I have a suspicion that at least part of the
motivation for the '%f' -> '%g' switch is that it means the
implementation can use a fixed-size buffer.  But Eric has
fixed this (in 3.1, at least) and the buffer is now dynamically
allocated, so this isn't a concern any more.


I agree that this is a big part of the reason it was done. There's still 
some work to be done in the fallback code which we use if we can't use 
Gay's implementation of _Py_dg_dtoa. But it's reasonably easy to 
calculate the maximum buffer size needed given the precision, for 
passing on to PyOS_snprintf. (At least I think that sentence is true, 
I'll very with Mark offline).



Other reasons not to switch from '%f' to '%g' in this way:

 - the change isn't gentle:  as you go over the 1e50 boundary,
   the number of significant digits produced suddenly changes
   from 56 to 6;  it would make more sense to me if it
   stayed fixed at 56 sig digits for numbers larger than 1e50.


This is the big reason for me.


 - float formatting is already quite complicated enough; no
   need to add to the mental complexity


And this, too.


(2) complex str and repr don't behave like float str and repr, in that
the float version always adds a trailing '.0' (unless there's an
exponent), but the complex version doesn't:

...

I propose changing the complex str and repr to behave like the
float version.  That is, repr(4. + 10.j) should be "(4.0 + 10.0j)"
rather than "(4+10j)".


I'm +0.5 on this. I'd probably be +1 if I were a big complex user. Also, 
I'm not sure about the spaces around the sign. If we do want the spaces 
there, we can get rid of Py_DTSF_SIGN, since that's the only place it's 
used and we won't be able to use it for complex going forward.


Eric.

___
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] Two proposed changes to float formatting

[Eric Smith]

Mark Dickinson wrote:

(1) Currently, '%f' formatting automatically changes to '%g' formatting for
numbers larger than 1e50.  For example:


'%f' % 2**166.

'93536104789177786765035829293842113257979682750464.00'

'%f' % 2**167.

'1.87072e+50'

I propose removing this feature for 3.1


I don't think we've stated it on this discussion, but I know from 
private email with Mark that his proposal is for both %-formatting and 
for float.__format__ to have this change. I just want to get it on the 
record here.


Eric.

___
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

[Python-Dev] Windows buildbots failing test_types in trunk

[Eric Smith]

Mark Dickinson pointed out to me that the trunk buildbots are failing 
under Windows.


After some analysis, I think this is because of a change I made to use 
_toupper in integer formatting. The correct solution to this is to 
implement issue 5793 to come up with a working, cross-platform, 
locale-unaware set of functions and/or macros for isdigit / isupper / 
toupper, etc.


I'll work on this tonight or tomorrow, at which point the Windows 
buildbots should turn green.


I don't think this affects py3k, although I'll port it there before the 
beta release.


Eric.
___
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] Dropping bytes "support" in json

[Eric Smith]

> I couldn't figure out a way to get rid of it short of multi-#including
> "templates" and playing with the C preprocessor, however, and have the
> nagging feeling the latter would be frowned upon by the maintainers.

Not sure if this is exactly what you mean, but look at Objects/stringlib.
str.format() and unicode.format() share the same implementation, using
stringdefs.h and unicodedefs.h.

Eric.

___
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: add support for UNC paths to all functions in ntpath

[Eric Smith]

Michael Foord wrote:

Larry Hastings wrote:


I've written a patch for Python 3.1 that changes os.path so it handles 
UNC paths on Windows:


  http://bugs.python.org/issue5799


+1 for the feature. I have to deal with Windows networks from time to 
time and this would be useful.


+1 from me, too. I haven't looked at the implementation, but for sure 
the feature would be welcome.



In the interests of full disclosure: I submitted a patch providing this
exact behavior just over ten years ago.  GvR accepted it into Python
1.5.2b2 (marked "*EXPERIMENTAL*") and removed it from 1.5.2c1.



In the intervening decade, two highly relevant things have happened:
* Python no longer uses ntpath for os.path on Cygwin.  Instead it uses
 posixpath.
* Cygwin removed the "//a/foo" drive letter hack.  In fact, I believe it
 now support UNC paths.
Therefore this patch will have no effect on Cygwin users.


Yes, cygwin supports UNC paths with //host/share, and they use 
/cygdrive/a, etc., to refer to physical drives. It's been that way for 
as long as I recall, at least 7 years.

___
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

[Python-Dev] svn down?

[Eric Smith]

When checking in, I get:

Transmitting file data .svn: Commit failed (details follow):
svn: Can't create directory 
'/data/repos/projects/db/transactions/72186-1.txn': Read-only file system


With 'svn up', I get:

svn: Can't find a temporary directory: Internal error

___
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

[Python-Dev] Changing float.__format__

[Eric Smith]

In issue 5920, Mark Dickinson raises an issue having to do with 
float.__format__ and how it handles the default format presentation type 
(that is, none of 'f', 'g', or 'e') versus how str() works on floats: 
http://bugs.python.org/issue5920


I agree with him that the current behavior is confusing and should be 
changed. I'm going to make this change, unless anyone objects. Please 
comment on the issue itself if you have any feedback.


Eric.
___
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: add support for UNC paths to all functions in ntpath

[Eric Smith]

Mark Hammond wrote:
Is that enough consensus for it to go in?  If so, are there any core 
developers who could help me get it in before the 3.1 feature freeze?  
The patch should be in good shape; it has unit tests and updated 
documentation.


I've taken the liberty of explicitly CCing Martin just incase he missed 
the thread with all the noise regarding PEP383.


If there are no objections from Martin or anyone else here, please feel 
free to assign it to me (and mail if I haven't taken action by the day 
before the beta freeze...)


Mark: I've reviewed this and it looks okay to me. It passes all the 
tests on Windows and Linux. But if you could take a look at it before 
the release tomorrow, I'd appreciate it.


I feel good enough about it to check it in if no one else gets to it.

Eric.

___
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

[Python-Dev] [Fwd: [Python-checkins] r72331 - python/branches/py3k/Modules/posixmodule.c]

[Eric Smith]

Modules/posixmodule.c now compiles for me, but I get a Bus Error in 
test_lchflags when running test_posixmodule on Mac OS X 10.5. I'll open 
a release blocker bug on this.


 Original Message 
Subject: [Python-checkins] r72331 - 
python/branches/py3k/Modules/posixmodule.c

Date: Tue,  5 May 2009 15:07:31 +0200 (CEST)
From: eric.smith 
To: python-check...@python.org

Author: eric.smith
Date: Tue May  5 15:07:30 2009
New Revision: 72331

Log:
Added missing semicolon.

Modified:
   python/branches/py3k/Modules/posixmodule.c

Modified: python/branches/py3k/Modules/posixmodule.c
==
--- python/branches/py3k/Modules/posixmodule.c  (original)
+++ python/branches/py3k/Modules/posixmodule.c  Tue May  5 15:07:30 2009
@@ -1928,7 +1928,7 @@
if (!PyArg_ParseTuple(args, "O&i:lchmod", PyUnicode_FSConverter,
  &opath, &i))
return NULL;
-   path = bytes2str(opath, 1)
+   path = bytes2str(opath, 1);
Py_BEGIN_ALLOW_THREADS
res = lchmod(path, i);
Py_END_ALLOW_THREADS
___
Python-checkins mailing list
python-check...@python.org
http://mail.python.org/mailman/listinfo/python-checkins

___
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] typo in 8.1.3.1. Format Specification Mini-Language?

[Eric Smith]

Neal Becker wrote:

"format_spec ::=  [[fill]align][sign][#][0][width][.precision][type]"
"The precision is ignored for integer values."

In [36]: '%3x' % 10
Out[36]: '  a'

In [37]: '%.3x' % 10
Out[37]: '00a'

Apparently, precision is _not_ ignored? 


That section is talking about this:

>>> format(10, '.3x')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Precision not allowed in integer format specifier
___
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] typo in 8.1.3.1. Format Specification Mini-Language?

[Eric Smith]

Eric Smith wrote:

Neal Becker wrote:

"format_spec ::=  [[fill]align][sign][#][0][width][.precision][type]"
"The precision is ignored for integer values."

In [36]: '%3x' % 10
Out[36]: '  a'

In [37]: '%.3x' % 10
Out[37]: '00a'

Apparently, precision is _not_ ignored? 


That section is talking about this:

 >>> format(10, '.3x')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Precision not allowed in integer format specifier


So I guess it shouldn't say "is ignored", it should be "is not allowed".
___
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

[Python-Dev] py3k build broken

[Eric Smith]

Tarek:

With you ARFLAGS change, I now get the following error on a 32 bit 
Fedora 6 box. I've done "make distclean" and "./configure":


$ make
...
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE  -I./Modules/_io -c 
./Modules/_io/textio.c -o Modules/textio.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE  -I./Modules/_io -c 
./Modules/_io/stringio.c -o Modules/stringio.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE  -c ./Modules/zipimport.c -o 
Modules/zipimport.o

./Modules/zipimport.c: In function ‘get_module_code’:
./Modules/zipimport.c:1132: warning: format ‘%c’ expects type ‘int’, but 
argument 3 has type ‘long int’
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE  -c ./Modules/symtablemodule.c 
-o Modules/symtablemodule.o
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE  -c ./Modules/xxsubtype.c -o 
Modules/xxsubtype.o
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes  -I. 
-IInclude -I./Include   -DPy_BUILD_CORE -DSVNVERSION=\"`LC_ALL=C 
svnversion .`\" -o Modules/getbuildinfo.o ./Modules/getbuildinfo.c

rm -f libpython3.1.a
ar @ARFLAGS@ libpython3.1.a Modules/getbuildinfo.o
ar: illegal option -- @
Usage: ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV] 
[member-name] [count] archive-file file...

   ar -M [  [u]  - only replace files that are newer than current archive 
contents

 generic modifiers:
  [c]  - do not warn if the library had to be created
  [s]  - create an archive index (cf. ranlib)
  [S]  - do not build a symbol table
  [v]  - be verbose
  [V]  - display the version number
  @  - read options from 
 emulation options:
  No emulation specific options
ar: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 
elf32-little elf32-big srec symbolsrec tekhex binary ihex trad-core

make: *** [libpython3.1.a] Error 1
___
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] py3k build broken

[Eric Smith]

Tarek Ziadé wrote:

On Thu, May 7, 2009 at 11:36 PM, Eric Smith  wrote:

With you ARFLAGS change, I now get the following error on a 32 bit Fedora 6
box. I've done "make distclean" and "./configure":


Sorry yes, I am on it now, the produced Makefile is broken, until then
you can change it

...

No problem. I'll wait.

___
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] py3k build broken

[Eric Smith]

Tarek Ziadé wrote:

I have fixed configure by runing autoconf, everything should be fine now


And indeed, it's working fine now, thanks.


Sorry for the inconvenience.


Not a problem. Anyone who volunteers for autoconf work gets a free pass 
from me.


Eric.

___
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] Shorter release schedule?

[Eric Smith]

Antoine Pitrou wrote:

Yes, I realized that's one of the problems with this proposal. If we had to
maintain more than one stable branch, it would become a burden.


Agreed. And since we have 2.x and 3.x now, we already have that problem. 
I'd like to an acceleration of release schedules (if it even happens) 
come after 2.x is retired.

___
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-checkins] r72995 - in python/branches/py3k: Doc/library/contextlib.rst Doc/whatsnew/3.1.rst Lib/contextlib.py Lib/test/test_contextlib.py Misc/NEWS

[Eric Smith]

raymond.hettinger wrote:

Author: raymond.hettinger
Date: Fri May 29 00:20:03 2009
New Revision: 72995

Log:
Deprecate contextlib.nested().  The with-statement now provides this 
functionality directly.

Modified:
   python/branches/py3k/Doc/library/contextlib.rst
   python/branches/py3k/Doc/whatsnew/3.1.rst
   python/branches/py3k/Lib/contextlib.py
   python/branches/py3k/Lib/test/test_contextlib.py
   python/branches/py3k/Misc/NEWS


Shouldn't the test cases exist as long as contextlib.nested still 
exists? We want to make sure it works, after all. I think they should be 
removed only when .nested is itself deleted.


Eric.

___
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] Binary Operator for New-Style String Formatting

[Eric Smith]

I'm against syntax for this, for all the reasons stated by others.

Jerry Chen wrote:

Just one last note: I think my end goal here was to preserve the
visual clarity and separation between format string and format
parameters, as I much prefer:

"%s %s %s" % (1, 2, 3)

over

"{0} {1} {2}".format(1, 2, 3)


If it helps, in 3.1 and 2.7 this can be written as
"{} {} {}".format(1, 2, 3)
I'm not sure it helps for "visual clarity", but it definitely makes the 
typing easier for simple uses.



The former is a style I've grown accustomed to, and if % is indeed
being slated for removal in Python 3.2, then I will miss it sorely
(or... just get over it).


I've basically come to accept that %-formatting can never go away, 
unfortunately. There are too many places where %-formatting is used, for 
example in logging Formatters. %-formatting either has to exist or it 
has to be emulated.


Although if anyone has any suggestions for migrating uses like that, I'm 
interested.


Eric.

___
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 376 - Open questions

[Eric Smith]

Antoine Pitrou wrote:

Paul Moore  gmail.com> writes:

I have no answer here. But I think we need feedback from the people
who will ultimately be building bdist_xxx formats - Debian packagers,
people wrting alternate RPM builders, etc.


I think any bdist_xxx command which targets externally handled package formats
(rpm, deb, msi, etc.) shouldn't generate RECORD. If you install with rpm or
dpkg, you will uninstall with the same tool, won't you?


I agree with this. For RPM's, there's a whole other database of what 
files were installed. Is it really the intent that a file will be 
managed by multiple different installers? That I can install with RPM 
but remove with some python-installer (or other) tool? That way lies 
madness. In fact, I see RECORD as an installer-specific detail that 
doesn't need to be standardized at all.


For bdist_rpm (which I'm contemplating taking over, but no promises), 
the only thing that needs to be done with the metadata is be able to 
build a .spec file. Once the .spec file is generated, rpmbuild (or 
equivalent) will produce the .rpm files. I image that .deb's are 
similar, but I'm no expert.


Which brings up the "static metadata" argument I was making at PyCon. I 
want there to be enough static metadata that the new bdist_rpm can read 
so that it produces a well-behaved .spec file. I need to know the intent 
of some of the files (which are documentation, which are config files, 
which are scripts, which are libraries, etc.) and not much else.


I envision the new bdist_rpm as a standalone tool, not a distutils 
extension.



Bottom line - Is RECORD to be created on the target machine at install
time, or must it be relocatable?


This is quite an uninformed opinion, but a relocatable RECORD looks like a can
of worms to me.


Agreed.


As for creating RECORD at install time, I don't understand the argument about
duplicate code. Distutils can provide useful primitives for generating RECORD,
so that interested subcommands don't have a lot of additional work to do.


I envision a "distlib" that contains new support code that's not part of 
the current distutils morass.

___
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 376 - Open questions

[Eric Smith]

P.J. Eby wrote:

At 08:59 AM 7/8/2009 -0400, Eric Smith wrote:
I agree with this. For RPM's, there's a whole other database of what 
files were installed. Is it really the intent that a file will be 
managed by multiple different installers? That I can install with RPM 
but remove with some python-installer (or other) tool? That way lies 
madness. In fact, I see RECORD as an installer-specific detail that 
doesn't need to be standardized at all.


This is a misunderstanding.  The purpose is to let an *installer* (like 
easy_install) know that these files belong to some other installer, and 
not allow overwriting them.  That's why there's also an INSTALLER file.


I really don't see this use case. Supporting multiple installers for the 
same file (or even just trying to prevent two installers from writing 
the same file)? Wouldn't you be better off just saying an installer 
can't overwrite any existing file?


Likewise, I don't see a use case for installing with one installer and 
uninstalling with another.


Put those two together, and the mechanism that an installer uses to 
record what files it installed is a private implementation detail.


Eric.

___
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 376 - Open questions

[Eric Smith]

Paul Moore wrote:

2009/7/8 P.J. Eby :

If it were being driven by setuptools, I'd have just implemented it myself
and presented it as a fait accompli.  I can't speak to Tarek's motives, but
I assume that, as stated in the PEP, the primary driver is supporting the
distutils being able to uninstall things, and secondarily to allow other
tools to be built on top of the API.


My understanding is that all of the various distutils PEPs were driven
by the "packaging summit" ay PyCon. The struggle here seems to be to
find *anyone* from that summit who will now comment on the discussion
:-(


I was there, and I've been commenting!

There might have been more discussion after the language summit and the 
one open space event I went to. But the focus as I recall was static 
metadata and version specification. When I originally brought up static 
metadata at the summit, I meant metadata describing the sources in the 
distribution, so that we can get rid of setup.py's. From that metadata, 
I want to be able to generate .debs, .rpms, .eggs, etc.


But I think we've veered into metadata that describes what has been 
installed. I don't think that's so useful. As I've said, this is private 
to the installers. If 2 installers want to communicate with each other 
about what they've installed, then they can agree on that data. I just 
don't find it generally useful for all installers, and therefore not 
useful for distutils.


I'd like to get back to the metadata that describes the source files. 
That's where the real value lies, in my opinion. I'll try and work on a 
post to distutils-sig explaining my thinking.



___
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 376 - Open questions

[Eric Smith]

Stephen J. Turnbull wrote:

Eric Smith writes:

 > But I think we've veered into metadata that describes what has been 
 > installed. I don't think that's so useful. As I've said, this is private 
 > to the installers. If 2 installers want to communicate with each other 
 > about what they've installed, then they can agree on that data. I just 
 > don't find it generally useful for all installers, and therefore not 
 > useful for distutils.


ISTM that the problem that it solves is uninstall in the absence of
the original installer.  Am I to understand that you don't think that
use case is important?  Or that there's another way to do this?


Yes, I think that's a use case that doesn't need to be supported by this 
PEP. It's an issue for a single installer, or a group of installers. 
It's not something that _all_ installers need to care about.

___
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 376 - Open questions

[Eric Smith]

Steven D'Aprano wrote:

On Thu, 9 Jul 2009 08:07:21 am Eric Smith wrote:

But I think we've veered into metadata that describes what has been
installed. I don't think that's so useful. As I've said, this is
private to the installers. If 2 installers want to communicate with
each other about what they've installed, then they can agree on that
data. I just don't find it generally useful for all installers, and
therefore not useful for distutils.


But doesn't this metadata give any two installers a common language to 
use to communicate, instead of having every pair of installers create 
their own private communication method?


I really don't get this use case of multiple installers trying to 
install the same package. There's just no way that running "yum install 
twisted" and "apt-get install twisted" and "pip install twisted" are 
going to coexist with each other. The best they can do is say "a file 
I'm trying to install already exists". Why try for anything else?


Personally, I like to be able to look at a package and say "What did 
that install?" Or contrary-wise, look at a file and say "What package 
installed that?"


I completely support that. All of the system installers I know of 
support this (at least on Linux; I'm familiar with the msi database 
layout (as exposed by Orca) on Windows, but I've never looked to see if 
they record the results of installing an msi). I just see this as an 
issue within each installer. Why would the installers need to 
communicate this with each other?


There are few things worse than discovering a bunch of 
mysterious executable files on your system that you don't remember 
installing, and then spending a few paranoid hours trying to determine 
whether you've stumbled across a root kit or virus or whether they have 
a legitimate reason to be there.


We can't solve the problem of "here's an arbitrary file on the system, 
where did it come from?". There are many, many installers outside of our 
control that might have installed something. Ruby has installers, Perl 
has installers, I'm sure there are hundreds of such installers. The user 
might have even used wget to install something.


___
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 376 - Open questions

[Eric Smith]

P.J. Eby wrote:

ISTM that the problem that it solves is uninstall in the absence of
the original installer.


Or uninstall where the installer is "setup.py install", actually.


I think we need to move away from "setup.py install". It's the 
antithesis of static metadata. setup.py needs to go away.


If we have a static metadata file called, say "setup.info", then I'd 
like to see:

"bdist_rpm setup.info" produce a .rpm
"bdist_msi setup.info" produce a .msi
"bdist_deb setup.info" produce a .deb
"bdist_egg setup.info" produce a .egg
and so on.

There might be a library (and I call dibs on the name "distlib" :) that 
provides support routines to parse setup.info, but there's no framework 
involved. And no need for a plugin system.


There might be support routines used to build setup.info. For those who 
think it's reasonable that the list of source files comes from your 
version control system, build a small command that produces setup.info 
from your vcs. If you need the version number to come from some other 
source, write a small command that reads that and sticks it into a 
setup.info. But the source distribution would be defined by a (possibly 
generated) setup.info.


The metadata in setup.info would be extensible. If setup.info contains 
information that's needed to build a .rpm that's not needed for a .deb, 
then that's fine. We can define the minimum information needed and an 
extension mechanism. As time goes by, some of the extensions might 
become standardized.


Then for each binary format, there's an installer (or more than one!), 
and it might handle dependency detection and automatic fetching, or it 
might not. Some of these exist (apt-get, yum, msi), some might need some 
tweaking (setuptools, pip) and others might need to be written from 
scratch. But the installer, its database of what it has installed, and 
how it handles uninstalls (if it does) is really not the issue.


It's the conflation of "build a package" with "install a package" that 
distutils and setuptools has given us (via setup.py) that leads to us 
never making progress. Let's just focus on "describe a package" and let 
the packagers handle "build a package" and let the installers handle 
"install and uninstall a package". Then the packagers (and their 
associated installers) can evolve independently of each other.

___
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 376 - Open questions

[Eric Smith]

Eventually, I'd like PEP 376 to support system packagers too. So for 
example, if you did "apt-get install python-pyqt4", then running "pip 
install python-pyqt4" should return without installing anything .. as 
RECORD will be part of the .deb previously installed. As for generating 
the RECORD file, I vote for generating it during install time (w/ 
absolute paths).


I think we should explicitly not support this. What if pip and apt-get 
(or rpm, or others) install the same package in different places because 
of system conventions (/usr vs. /usr/local vs. /opt, say)? There's no 
way we're ever going to get this right, and it's not worth complicating 
our lives over it.


Seriously: Is there some real world use case I'm missing? Does any 
existing install system support this?

___
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 376 - Open questions

[Eric Smith]

P.J. Eby wrote:

At 11:20 PM 7/8/2009 -0400, Eric Smith wrote:

P.J. Eby wrote:

ISTM that the problem that it solves is uninstall in the absence of
the original installer.

Or uninstall where the installer is "setup.py install", actually.


I think we need to move away from "setup.py install". It's the 
antithesis of static metadata.


Please note that that's entirely out of scope for the PEP at hand.


Yes. I'm just trying to point out that the information in the PEP is 
applicable only to the set of installers that want to work together in 
some integrated way. It doesn't apply to all installers, and I think 
that's the bigger problem.


But I grant you that the rest of my mail is veering off-topic, and 
there's a more appropriate thread now on distutils-sig.


Eric.

___
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] standard library mimetypes module pathologically broken?

[Eric Smith]

Benjamin Peterson wrote:

Then, you might garner some more reviews by putting your patch up on
Rietveld; it makes reviewing much painful.


"... much _less_ painful", I hope!

___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Eric Smith]

Peter Moody wrote:

On Wed, Aug 19, 2009 at 3:20 AM, Antoine Pitrou wrote:

Le Tue, 18 Aug 2009 13:00:06 -0700, Peter Moody a écrit :

Howdy folks,

I have a first draft of a PEP for including an IP address manipulation
library in the python stdlib. It seems like there are a lot of really
smart folks with some, ahem, strong ideas about what an IP address
module should and shouldn't be so I wanted to solicit your input on this
pep.

When you say :

« the results of the first computation should be cached and only
re-generated should the object properties change »

does it mean that the objects are mutable? Would it make sense to make
them immutable and therefore hashable (such as, e.g., datetime objects)?


that's a good point. I'll implement __hash__ in the BaseIP class.


But are the objects mutable? I haven't had time to deep dive on this 
yet, but I'd like to. I also use IPy and would like to some this in the 
stdlib.


Eric.
___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Eric Smith]

Peter Moody wrote:

On Wed, Aug 19, 2009 at 9:21 AM, R. David Murray wrote:



Possibly.  Tino means exactly what he said:  the broadcast address
does not _have_ to be the last IP, nor does the last IP _have_ to be
a broadcast, though in practice they almost always are (and using the
last IP as a host IP almost never works in practice in a heterogeneous
network).  Check out the 'broadcast' option of the ifconfig command for
confirmation that the broadcast address can be any IP in the network.
Of course, for that to work all hosts on the network have to agree on
what the broadcast is, hence the normal convention that the broadcast
is the last IP in the network.

As for the 'network' attribute, if you call it 'network' IMO it should
be a network data type, which would make it rather redundant.  What you
are actually returning is what I have normally heard called either the
'zero' of the network, or the "network number" or "network identifier";
but never just "network" (a network has to have at least an implicit
netmask to be meaningful, IMO).

Since you are dealing with networks as a list of addresses, perhaps
you should drop the 'network' attribute, make the 'broadcast' attribute
settable with a default equal to self[-1], and let the user refer to
the zero element to get the zero of the network if they want it.


making the broadcast address settable (with a default to self[-1])
might be reasonable, though it is different from just about every
other python implementation I've seen (IPy, ipv4.py, netaddr).

I'm not sure I understand your point about the network attribute.
what I'm returning with network is the subnet-id/base address of the
given network. Again, .network seems to be fairly standard for naming.


I think using .network and .broadcast are pretty well understood to be 
the [0] and [-1] of the network address block. I don't think we want to 
start creating new terms or access patterns here.


+1 on leaving .network and .broadcast as-is (including returning a 
IPvXAddress object).


Eric.
___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Eric Smith]

Glyph Lefkowitz wrote:
On Wed, Aug 19, 2009 at 2:20 PM, Eric Smith <mailto:e...@trueblade.com>> wrote:
 


I think using .network and .broadcast are pretty well understood to
be the [0] and [-1] of the network address block. I don't think we
want to start creating new terms or access patterns here.

+1 on leaving .network and .broadcast as-is (including returning a
IPvXAddress object).


-1.  I think 'network.number' or 'network.zero' is a lot clearer than 
'network.network'.  Maybe '.broadcast' would be okay, as long as it 
/can/ be adjusted for those unusual, or maybe even only hypothetical, 
networks where it is not the [-1].


Is there some existing library that uses .number or .zero? IPy uses .net 
(and .broadcast for [-1]).


___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Eric Smith]

[Glyph]
So it sounds like doing what I suggested earlier (default to [-1], allow 
for customization) is actually required by the RFC :-).  Although it 
does sound like the RFC only requires that you be able to customize to 
[0] rather than [-1], rather than any address.  In practical terms 
though I believe it is possible to do as Tino suggests and configure any 
crazy address you want to be the broadcast address (or addresses, even) 
for a network.


If you're doing this, are you really going to be specifying the 
broadcast address as something like network.use_broadcast_index(-2) (or 
even 0) and then using network.broadcast somewhere else? I just don't 
see that happening.


[Martin]


I think setting the broadcast address to something else just does
not need to be supported.


I agree.

[Glyph]
It is unusual, but frankly, needing to actually do operations on 
broadcast addresses at all is also a pretty unusual task.  Broadcast 
itself is a somewhat obscure corner of networking.  I suspect that in 
many deployments that need to write significant code to deal with 
broadcast addresses, rather than the usual default stuff, funky 
configurations will actually be quite common.


I use .broadcast from IPy, and I'm not doing anything funky. All of my 
broadcast addresses are network[-1].



___
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 3144: IP Address Manipulation Library for the Python Standard Library

[Eric Smith]

Fred Drake wrote:

On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:

just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?



The name would be confusing, though.  Perhaps using_prefix() would be 
more clear.


I think you'd be better off either doing this with an optional parameter 
to __init__, or a class method factory function (maybe from_prefix or 
similar). I don't see why it should be a method on an existing object.

___
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] Decorator syntax

[Eric Smith]

Erik Bray wrote:

I think Guido may have a point about not allowing any arbitrary
expression.  But I do think that if it allows calls, it should also at
least support the itemgetter syntax, for which there seems to be a
demonstrable use case.  But that's just adding on another special
case, so it might be simpler to allow arbitrary expressions.


It's not the same issue, of course, but note that str.format's object 
specification "language" supports item and attribute access. And that's 
the extent of what it allows.


If you wanted to do this for decorators, I'm not sure how easy it would 
be to restrict the expression inside the brackets, or if you'd even want 
to. str.format has all of this baked-in, it doesn't use any sort of grammar.


Eric
___
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

[Python-Dev] Numeric alignment issue with PEP 3101

[Eric Smith]

The default string formatting alignment for all types, according to PEP 
3101, is left aligned. Issue 6857 (http://bugs.python.org/issue6857) 
points out that for numeric types (int, float, and decimal, at least), 
the actual implemented default alignment is right aligned.


Mark Dickinson and I agree that for numeric types, right alignment makes 
much more sense as a default. And that's what %-formatting and 
str.format() both do.


I think the PEP should be modified to say that right alignment is the 
default for numeric types. Also the documentation at 
http://docs.python.org/library/string.html#formatstrings should have the 
same modification.


Does anyone disagree?

Eric.
___
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] Numeric alignment issue with PEP 3101

[Eric Smith]

Greg Ewing wrote:

Is the new formatting supposed to behave the same way
as %-formatting for the same format codes? Because the
default for %-formatting is actually right alignment
for *all* types, including strings.


Hmm, I never noticed that. At this point, I think changing the 
formatting for any types would break code, so we should just change the 
documentation to reflect how currently works.


Eric.

___
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] Numeric alignment issue with PEP 3101

[Eric Smith]

Mark Dickinson wrote:

On Mon, Sep 7, 2009 at 11:10 PM, Eric Smith wrote:

Hmm, I never noticed that. At this point, I think changing the formatting
for any types would break code, so we should just change the documentation
to reflect how currently works.


I think the alignment for Decimal *does* need to be changed, though.  It
currently left-aligns by default (my fault:  I just blindly followed PEP 3101
without thinking too hard about it).  I'd like to fix this for 3.2 and 2.7; I'm
not sure whether it's too disruptive to fix it in 3.1 and 2.6.


Right, not changing "any types" was too strong. I think that the numeric 
types should all default to right alignment. That means Decimal should 
change. I agree this should only be in 3.2 and 2.7. In addition, PEP 
3101 and the documentation should be change to reflect the default right 
alignment for numeric types.


Shame on you, Mark, for actually reading and implementing the specs! ;) 
You see that I didn't bother with that. At the time, I think I was 
trying to get str.format() to exactly agree with %-formatting.

___
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] Numeric alignment issue with PEP 3101

[Eric Smith]

> Mark Dickinson wrote:
>> I think the alignment for Decimal *does* need to be changed, though.  It
>> currently left-aligns by default (my fault:  I just blindly followed PEP
>> 3101
>> without thinking too hard about it).  I'd like to fix this for 3.2 and
>> 2.7; I'm
>> not sure whether it's too disruptive to fix it in 3.1 and 2.6.

I notice that complex has the same problem as the just-fixed Decimal. I'll
make those changes.
___
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 3144 review.

[Eric Smith]

Antoine Pitrou wrote:

Peter Moody  hda3.com> writes:

However, I do not think
that the proposed API should accept, eg, IPv4Network('192.168.1.1/24')
as valid.  That's just too confusing and error prone.

Indeed, it should throw some kind of ValueError instead.

Peter, what do you think?

I disagree. It seems overly pedantic to throw a valueerror on this.
IPy does (used to do?) this and it's one of the primary reasons I
wrote ipaddr.


Python is not PHP and does not try to be overly "smart" or tolerant when faced
with bizarrely-formatted input.

I don't see any valid reason for entering a network as "192.168.1.1/24" rather
than the canonical "192.168.1.0/24". The former might indicate a typing error or
a mental slip, so let's be helpful and signal it to the user.


I completely agree. I don't know of any situation where I'd want a 
network of "192.168.1.1/24" to be anything other than an error.


Eric.
___
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 3144 review.

[Eric Smith]

Antoine Pitrou wrote:

Antoine Pitrou  pitrou.net> writes:

I don't see any valid reason for entering a network as "192.168.1.1/24" rather
than the canonical "192.168.1.0/24". The former might indicate a typing error
or
a mental slip, so let's be helpful and signal it to the user.


Or perhaps there can be an optional "strict=True" (or "strict=False") argument
to the constructor / parsing function.


If so, I hope that we'd default to strict=True.
___
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 Language Summit #2 in February

[Eric Smith]

A.M. Kuchling wrote:

We therefore need to decide what those three sessions should be about.
Please discuss on python-dev and hopefully we can arrive at some
consensus on topics of reasonably wide current interest.  (See
http://us.pycon.org/2009/about/summits/language/ for a reminder of
last year's topics.)


I'd like to have a discussion on the future of 2.x, at least as far as 
core development goes. Supporting both 2.x and 3.x cuts my contributions 
in half, at best. For example, in order to keep 2.x and 3.x nearly in 
sync, Mark and I back-ported the API's for short-float-repr to 2.x, even 
though 2.x itself didn't see any benefit from that work (well, at least 
not much of a benefit).


My initial thought is let's stop after 2.7 (if we even release 2.7). But 
it all depends on uptake of 3.x, and what stopping core development 
means to the community.


Can we discuss this at the language summit?

Eric.
___
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 3144 review.

[Eric Smith]

Eric.

"Greg Ewing"  wrote:

>Nick Coghlan wrote:
>
>> Or, to put it another way, given an arbitrary host in a network (e.g.
>> your own machine or the default gateway) and the netmask for that
>> network, calculate the network address.
>
>Some people have claimed that the gateway address of a
>network isn't necessarily the zero address in that network.
>If that's true, then you *can't* calculate the network
>address from a host address and a netmask -- there isn't
>enough information. Furthermore, an IPNetwork object
>needs to be able to represent a network address whose
>address part contains bits that aren't in the mask.

I don't see why that would be considered a network address, then. It sounds to 
me like that's a host address plus a netmask.___
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] conceptual clarity

[Eric Smith]

Antoine Pitrou wrote:

Le Thu, 17 Sep 2009 14:30:28 +1200, Greg Ewing a écrit :

3) an Address with an attached Network

An Address could be constructed in three ways:

   Address(ip_number)

   Address(ip_number, network = )

   Address(ip_number, mask = )
 # constructs and attaches a suitably-masked Network instance

We could also have some_network[n] return an Address referring back to
the network object it was obtained from.


It seems you are uselessly conflating two perfectly distinct concepts: 
Address and Network. You also haven't addresses the issue of comparing 
together (and hashing) two addresses with the same IP but pointing to a 
different network. No answer to this issue seems satisfactory and 
obviously right.


As it is, -1 from me. Either we only keep two concepts (Address and 
Network), or if we introduce a third one (AddressWithMask, whatever) for 
added practicality; but we shouldn't blur the line between the two former 
canonical concepts under the pretext that a platypus-like Address might 
be helpful in some particular situations.


I completely agree with this. By keeping the concepts distinct we can 
catch mis-uses earlier. If needed, convenience functions (or classes, or 
whatever) could be layered on top. But the underlying concepts need to 
be clear.


Eric.

___
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] conceptual clarity

[Eric Smith]

Nick Coghlan wrote:

Eric Smith wrote:

Antoine Pitrou wrote:

As it is, -1 from me. Either we only keep two concepts (Address and
 Network), or if we introduce a third one (AddressWithMask,
whatever) for added practicality; but we shouldn't blur the line
between the two former canonical concepts under the pretext that a
platypus-like Address might be helpful in some particular
situations.

I completely agree with this. By keeping the concepts distinct we can
 catch mis-uses earlier. If needed, convenience functions (or
classes, or whatever) could be layered on top. But the underlying
concepts need to be clear.


That would be my view as well (this includes getting rid of the current
duality of IPNetwork by dropping the ip property, only accepting the
network address in the normal constructor and having a separate
constructor that allows a network object to be created from an arbitrary
  host address and a netmask)


Yes, I think that's the best plan. I could live without AddressWithMask 
(or whatever name), but it would be a nice convenience.



Is-a-2.x-str-a-sequence-of-ASCII-characters-or-a-chunk-of-binary-data?'ly,


LOL! Perfect.

Eric.
___
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 3144 review.

[Eric Smith]

Nick Coghlan wrote:

To be honest, given the indexing behaviour, I'm -1 on the idea of giving
the network address or broadcast address attribute names *at all*. Consider:

  network_address = my_net[0]
  broadcast_address = my_net[-1]


My only concern with this is a possible performance issue with v6 
networks. Would this be implemented such that [-1] doesn't need to 
iterate through the (possibly large) address space of a v6 network?


I think it could (and would) be implemented efficiently, so I'm +1 on 
not giving these names, but adding this "recipe" to the documentation 
instead.


Eric.

___
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 3144 review.

[Eric Smith]

Peter Moody wrote:


indexing is plenty efficient, but the problem is that these names for
these attributes are common to the point of causing confusion if
they're omitted.


After thinking about it some more, I'm okay with names for [-1] and [0]. 
I like .broadcast, and I can live with .network (although it's 
confusing, since in my view it should return an address, not a network).


Eric.
___
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] Misc/maintainers.rst

[Eric Smith]

R. David Murray wrote:

On Thu, 17 Sep 2009 at 10:57, Brett Cannon wrote:

Looks great to me! Only thing missing that I can think of is sticking
Eric down as the guy who does str.format(). =)


OK, I've added that one to the last table ;)


Awesome! I get to spend even more time on formatting strings!

I kid. I'm happy to be the string formatting maintainer.


___
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 3144 review.

[Eric Smith]

Cameron Simpson wrote:

On 18Sep2009 07:48, Nick Coghlan  wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they're omitted.
| > 
| > After thinking about it some more, I'm okay with names for [-1] and [0].

| > I like .broadcast, and I can live with .network (although it's
| > confusing, since in my view it should return an address, not a network).
| 
| And in fact *does* return an Address - the same address that my_net[0]

| returns.

Yes, I think Eric was complaining about the name being "network", since
we have Network objects and this isn't one.


Right. thing_commonly_referred_to_as_network_but_is_an_address.

___
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] operator precedence of __eq__, __ne__, etc, if both object have implementations

[Eric Smith]

s...@pobox.com wrote:

Dino> For IronPython we wrote a set of tests which go through and define
Dino> the various operator methods in all sorts of combinations on both
Dino> new-style and old-style classes as well as subclasses of those
Dino> classes and then do the comparisons w/ logging.

It would be very nice if these complex corner cases had a set of test
cases which could be run by all implementations (CPython, Jython,
IronPython, PyPy, etc).  I don't know.  Maybe the CPython test suite serves
that purpose, but it seems like it would be helpful if this sort of
"validation suite" was maintained as a separate project all implementations
could use and contribute to.


IIRC, one of the reasons for "breaking out"[1] the standard library (and 
its test suite) was to allow for things like this.


Eric.

[1] For whatever definition "breaking out" ends up having.

___
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] thinking about 2.7

[Eric Smith]

Michael Foord wrote:

Benjamin Peterson wrote:

2009/9/23 Michael Foord :
 

Benjamin Peterson wrote:
   

2009/9/23 Michael Foord :

 

Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...



Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite could have shown on a platform.



  
Well, Trent Nelson is going to devote some real time to Snakebite - 
so there

is a very good chance that it will be up and active before the release.
Naturally I agree it would be *preferable* to run tests on all supported
platforms prior to release.



Could I inquiry about your source of this information?



  
 From Trent on the snakebite mailing list. Too late for me to look it up 
though; an exercise I leave to the reader.


http://groups.google.com/group/snakebite-list/browse_thread/thread/d08642261f2cc502

Eric.

___
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 3144 review.

[Eric Smith]

R. David Murray wrote:

The fundamental divide here is between two behaviors.

ipaddr:

>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
False
>>> x.ip
IPv4Address('192.168.1.1')

desired:

>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
True
>>> x.ip
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'IPv4Network' object has no attribute 'ip'

Everything else is pretty much bikeshedding and can be dealt with.  This
is fundamental and Peter has indicated he will not change it.


I think that's an excellent summary, David. And I'm -1 unless it changes 
to the "desired" behavior above.


Eric.
___
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 3144 review.

[Eric Smith]

Mark Dickinson wrote:

On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
 wrote:

On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan  wrote:

I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:

   >>> x = IPv4Network('192.168.1.1/24')
   >>> y = IPv4Network('192.168.1.0/24')
   >>> x == y # Equality is the part I really want to see changed
   True
   >>> x.ip
   IPv4Address('192.168.1.1')
   >>> y.ip
   IPv4Address('192.168.1.0')

With those semantics, IPv4Network objects with distinct IP addresses (but
the same network) could no longer be stored in a dictionary or set.  IMO, it
is a little counter-intuitive for objects to compare equal yet have
different properties.  I don't think this is a good compromise.


This worries me too.  It seems like a potentially dangerous half-measure.


I agree. I think keeping the concepts distinct and adding 2 new classes 
is a better solution.


Eric.

___
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 389: argparse - new command line parsing module

[Eric Smith]

Paul Moore wrote:

2009/9/28 Yuvgoog Greenle :

1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an interpreter).


That one does worry me. I'd rather argparse (or any library function)
didn't call sys.exit on my behalf - it should raise an exception. Is
it actually true that argparse exits? (I can imagine that it might if
--help was specified, for example. An exception may not be right here,
but I still don't like the idea of a straight exit - I've used too
many C libraries that think they know when I want to exit).


You can override ArgumentParser.error() to raise an exception.


2. There is no chance the parser will print things I don't want it to print.


That may also be bad - for example, Windows GUI-mode programs raise an
error if they write to stdout/stderr. I could imagine using argparse
for such a program, and wanting to do something with --help other than
write to stdout and exit (a message box, for example). And yet, I'd
want access to the text argparse would otherwise write to stdout.


It looks like this might not be so easy to do. I'd suggest adding a 
file-like object to the constructor, defaulting to sys.stderr; or maybe 
an ArgumentParser.print() method that can be overridden.


Eric.
___
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] transitioning from % to {} formatting

[Eric Smith]

Martin v. Löwis wrote:

Steven Bethard wrote:

There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting. 


I don't agree that we should do that. I see nothing wrong with using
% substitution.


It's a maintenance burden. There are several outstanding bugs with it, 
admittedly not of any great significance. I've been putting time into 
fixing at least one of them. When Mark and I did short-float-repr, at 
least half of my time was consumed with %-formatting, mostly because of 
how it does memory management.


On the plus side, %-formatting is (and always will be) faster than 
str.format(). Its very limitations make it possible for it to be fast.


I'd note that PEP 3101 calls str.format() a replacement for 
%-formatting, not an alternate mechanism to achieve the same end.



* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.


It's also ugly because the class has the word "new" in its name, which
no class should ever have. In a few years, it would still be around,
but not new anymore.


* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.


I don't see the point of having a converter. The tricky part, as you
say, is the guessing. Whether the implementation then converts the
string or has two alternative formatting algorithms is an implementation
detail. I would favor continued use of the actual % substitution
code.


Having a converter and guessing are 2 distinct issues. I believe a 
convert from %-formatting specification strings to str.format() strings 
is possible. I point this out not because I think a converter solves 
this problem, but because in the past there's been a debate on whether a 
converter is even possible.


Eric.

___
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] transitioning from % to {} formatting

[Eric Smith]

Vinay Sajip wrote:

Good point as far as the general case is concerned, though it's perhaps not that
critical for logging. By which I mean, it's not unreasonable for
Formatter.__init__ to grow a "style" keyword parameter which determines whether
it uses %-, {}- or $-formatting. Then the formatter can look for '%(asctime)s',
'{asctime}' or '$asctime' according to the style. 


It's tangential, but in the str.format case you don't want to check for 
just '{asctime}', because you might want '{asctime:%Y-%m-%d}', for example.


But there are ways to delay computing the time until you're sure it's 
actually being used in the format string, without parsing the format 
string. Now that I think of it, the same technique could be used with 
%-formatting:


import datetime

class DelayedStr:
def __init__(self, fn):
self.fn = fn
self.obj = None
def __str__(self):
if self.obj is None:
self.obj = self.fn()
return self.obj.__str__()

def current_time():
print "calculating time"
return datetime.datetime.now()

# will not compute current time
print '%(msg)s' % {'asctime':DelayedStr(current_time),
   'msg':'test'}

# will compute current time: same dict used as before
print '%(asctime)s %(msg)s' % {'asctime':DelayedStr(current_time),
   'msg':'test'}

Eric.


___
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] transitioning from % to {} formatting

[Eric Smith]

Antoine Pitrou wrote:

Vinay Sajip  yahoo.co.uk> writes:

"%0#8x" % 0x1234

'0x001234'

"{0:0>#8x}".format(0x1234)

'000x1234'


Apart from the sheer unreadability of the {}-style format string, the result 
looks rather unexpected from a human being's point of view.


(in those situations, I would output the 0x manually anyway, such as:

"0x%06x" % 0x1234

'0x001234'

"0x{:06x}".format(0x1234)

'0x001234'
)


"#" formatting was added to int.__format__ in order to support this case:

>>> format(10, '#6x')
'   0xa'

Without '#', there's no way to specify a field width but still have the 
'0x' up against the digits (at least not without generating an 
intermediate result and figuring out the width manually).


The fact that it works in combination with '0' or '>' (not sure which 
one makes it unreadable to you) wasn't really the point of the feature.


Eric.

___
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] transitioning from % to {} formatting

[Eric Smith]

Vinay Sajip wrote:

BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.


I didn't get your message, could you resend?.

I was thinking the same thing, but it seems like a transition step. I'd 
rather not keep such backward compatibility hacks (if you will) around 
for the long haul.  How about a flag (maybe '*') at the start of the 
format specification which says "operate in backward compatibility 
mode"? We could document it as being only useful for the % to {} 
translator, and promise to remove it at some point in the future. Either 
actually deprecate it or just promise to deprecate it in the future.


Eric.

___
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] transitioning from % to {} formatting

[Eric Smith]

Christian Tanzer wrote:

Eric Smith wrote at Thu, 08 Oct 2009 10:24:33 -0400:


Vinay Sajip wrote:

BTW I sent Eric a private mail re. the "0o" versus "0" issue, to see if it was
worth raising an enhancement request on the bug tracker using "O" to generate
compatible rendering for octals.

I didn't get your message, could you resend?.

I was thinking the same thing, but it seems like a transition step. I'd
rather not keep such backward compatibility hacks (if you will) around
for the long haul.  How about a flag (maybe '*') at the start of the
format specification which says "operate in backward compatibility
mode"? We could document it as being only useful for the % to {}
translator, and promise to remove it at some point in the future. Either
actually deprecate it or just promise to deprecate it in the future.


That doesn't seem very useful to me. IIUC, the point of the translator
is to allow porting of the millions of existing %-formating operations
to the new-style .format.

If the result of that is deprecated or removed a few years from now,
all maintainers of long existing code have exactly the same problem.


I was thinking of it as a transition step until all application code 
switched to {} formatting. In which case the application has to deal 
with it.



IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.


I disagree. I doubt even 0.001% of all format strings involve octal 
formatting. Is it really worth not providing a transition path if it 
can't cover this case?


Eric.

___
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] transitioning from % to {} formatting

[Eric Smith]

Benjamin Peterson wrote:

2009/10/8 Eric Smith :

Christian Tanzer wrote:

IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.

I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not providing a transition path if it can't
cover this case?


It's also really easy to just write 0{:o} like my translator does.




I apologize for not having looked at anyone's implementation yet. But I 
suspect you'll have a problem with this case unless int.__format__ has 
special logic for backward compatible octal formatting:


>>> '%# 5o' % 8
'  010'

Eric.

___
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] transitioning from % to {} formatting

[Eric Smith]

Nick Coghlan wrote:

Benjamin Peterson wrote:

2009/10/8 Eric Smith :

Christian Tanzer wrote:

IMHO, either the translation is done once and gives identical output or
it isn't worth doing at all.

I disagree. I doubt even 0.001% of all format strings involve octal
formatting. Is it really worth not providing a transition path if it can't
cover this case?

It's also really easy to just write 0{:o} like my translator does.


That works so long as the original format string doesn't specify either
a space padded field width or else a sign character. For those the extra
zero needs to be inserted after the leading characters but before the
number, so the formatting engine really has to handle it.

I'm actually thinking that having the ability to specify a single 0 as
the leading character for octal output is a legitimate feature. There
are plenty of other tools out there that use a single leading zero to
denote octal numbers (e.g. think of a Python script that generated C
code), so having Python be able to produce such numbers makes a lot of
sense.

Vinay's suggestion of using 'O' instead of 'o' to denote C-style octal
formatting instead of Python-style sounds reasonable to me (similar in
degree to the upper vs lower case distinction for 'x' and 'X' hex
formatting).


Mark points out in http://bugs.python.org/issue7094 that we'd also need 
to add alternate float formatting for any automated translation facility 
to work flawlessly. There might be other float issues involving trailing 
decimals with no zeros that work differently, too.


Eric.
___
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] Initialization of __builtins__

[Eric Smith]

Vinay Sajip wrote:

If __builtins__ is an implementation detail which can't be relied on, should the
py3k code be changed to the try: form? Or shall I just remove the checks
altogether, since Unicode should always be there in 3.x?


Remember that the identifier "unicode" isn't present in py3k. There it's 
"str" and it holds Unicode strings.


Unless you're trying to keep the code identical in both branches, I'd 
just remove the check in py3k and assume str is what you always want to use.


Eric.


___
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] Backport new float repr to Python 2.7?

[Eric Smith]

Glyph Lefkowitz wrote:

I'd much rather have my doctests and float-repr'ing code break on 2.7 so 
I can deal with it as part of a minor-version upgrade than have it break 
on 3.x and have to deal with this at the same time as the unicode->str 
explosion.  It feels like a backport of this behavior would make the 
2->3 transition itself a little easier.


I'm +0 on making the change, primarily for this reason.

We can reuse the vast majority of the code from 3.x.

Eric.
___
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] Backport new float repr to Python 2.7?

[Eric Smith]

[Tim:]
> If you don't consider Windows to be a major platform ;-)  Besides that
> there's just no guessing what the Microsoft double->string routines
> will produce for the 17th digit, the MS routines always produce 3
> digits for the exponent in scientific notation, while AFAIK all other
> platforms produce 2 digits when 3 aren't necessary.  For example, on
> Windows under Python 2.x:
>
 repr(1e47)
> '1e+047'
 repr(1e-47)
> '9.9997e-048'
>
> and "everywhere else":
>
 repr(1e47)
> '1e+47'
 repr(1e-47)
> '9.9997e-48'

Not that it's germane to the discussion, but this 3 digit exponent on
Windows was fixed in 2.6.

> The leading 0 in the Window's exponents is enough to break a naive
> doctest too -- and repr(x) does produce scientific notation for
> "almost all" finite doubles.  Why people are obsessed with the
> relative handful of doubles between 1 and 1000 is beyond me ;-)
>
> As doctest's original author, I have no sympathy for users who burn
> themselves with float output.  Of course it's open to question whether
> I have sympathy for anyone, ever, but that's not the issue here ;-)

I agree, we shouldn't base the decision to change this based on doctests.
___
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] Can 3.1 still be built without complex?

[Eric Smith]

s...@pobox.com wrote:

I notice that WITHOUT_COMPLEX still appears in Python.h and several .c files
but nowhere else in the 2.6, 2.7 or 3.1 source, most particularly not in
configure or pyconfig.h.in.  Are builds --without-complex still supported?
Has it been tested at any time in the recent past?


I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k 
branches. In py3k, it's referenced in:


./Include/Python.h
./Misc/HISTORY
./Objects/complexobject.c
./Objects/object.c
./Parser/tokenizer.c
./Python/ast.c
./Python/bltinmodule.c
./Python/getargs.c
./Python/marshal.c
./Python/modsupport.c

I checked complexobject.c, and it looks like it's used correctly there.

Eric.
___
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] Can 3.1 still be built without complex?

[Eric Smith]

s...@pobox.com wrote:
Eric> I haven't tested it, but I still see WITHOUT_COMPLEX in trunk and py3k 
Eric> branches. In py3k, it's referenced in:

...

Sure, but is it ever exercised?  A name like WITHOUT_COMPLEX suggests that
it should be flipped on/off by configure using --without-complex, but that
script doesn't know about it and it's not mentioned in pyconfig.h.in, where
the various --with-* flags work their magic.


Ah, I misunderstood. I thought you were asking "does setting 
WITHOUT_COMPLEX work?"


No idea about any configure option, sorry.

Eric.
___
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] SIGCHECK() in longobject.c

[Eric Smith]

> On Tue, Oct 20, 2009 at 11:49 AM, Nick Coghlan  wrote:
>> Mark Dickinson wrote:
>>> This high-precision inefficiency could easily be fixed by
>>> using a dedicated 'decimal natural number' extension
>>> type for the Decimal coefficient, stored internally in base
>>> a suitable power of 10. [...]
>>
>> Didn't you already start work on that concept with the deccoeff patch?
>
> I did:  the code can be seen at:
>
> http://svn.python.org/view/sandbox/trunk/decimal/decimal_in_c/
>
> This code defines a Deccoeff type as above, providing base 10 natural
> number arithmetic, along with a skeletal _Decimal type.  The work on
> Deccoeff is pretty much complete, but the _Decimal type is only just
> a beginning;  the original intent was to slowly translate the Decimal
> code into C and move it into the _Decimal type.
>
> The code was working a few months ago (with all Decimal tests
> passing), but there have been some changes and bugfixes since
> then.  I might try to resurrect that code, dropping the _Decimal type and
> just concentrating on Deccoeff.

My only concern about this is the effect it would have on IronPython,
Jython, PyPy, and other alternate implementations that use the stdlib.

___
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] Bizarre mtime behaviour

[Eric Smith]

Antoine Pitrou wrote:

Adam Olsen  gmail.com> writes:

Looks like an OS bug to me.  Linux I'm guessing?


Yes, but only on certain boxes. I could never reproduce on my home box.
RDM (David)'s buildbot is a Gentoo vserver with a reiserfs filesystem.


You'll occasionally see something similar on Windows boxes running FAT, 
because the timestamps stored in the filesystem have a 2 second 
granularity there. Not sure if this might be similar, or just a reiserfs 
issue.


Eric.
___
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] 2.7 Release? 2.7 == last of the 2.x line?

[Eric Smith]

s...@pobox.com wrote:

mal> I don't think users will really go for carrots. Python 2.x is
mal> mature enough already and at least the users I know are really
mal> happy with it (including myself).

Taking that thought further back one step (or three), from

http://effbot.org/tkinterbook/listbox.htm

I pull this quote:

In versions before Python 1.5, use string.atoi instead of int.


Which reminds me: I've been meaning to add -3 warnings for these string 
module functions!


Eric.
___
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