Stephen J. Turnbull wrote:
Robert Brewer writes:
> Syntactically, there's no sense in providing:
>
> Message.set_header('Subject', 'Some text', encoding='utf-16')
>
> ...since you could more clearly write the same as:
>
> Message.set_header('Subject', 'Some text'.encode('utf-16
Barry Warsaw wrote:
>>> message['Subject']
The raw bytes or the decoded unicode?
A header object.
Okay, so you've picked one. Now how do you spell the other way?
str(message['Subject'])
bytes(message['Subject'])
Now, setting headers. Sometimes you have some unicode thing and
sometimes
Nick Coghlan wrote:
Barry Warsaw wrote:
Of course, one could use message.header and message.bythdr and they'd
be the same length.
I was trying to figure out what a 'thdr' was that we'd want to index
'by' it. :)
In the discussions about os.environ, the suggested approach was to just
tack a 'b
gl...@divmod.com wrote:
My preference would be that
message.headers['Subject'] = b'Some Bytes'
would simply raise an exception. If you've got some bytes, you should
instead do
message.bytes_headers['Subject'] = b'Some Bytes'
Remind me again why you need to differentiate between hea
M.-A. Lemburg wrote:
"""
If the package really requires adding one or more directories on sys.path (e.g.
because it has not yet been structured to support dotted-name import), a "path
configuration file" named package.pth can be placed in either the site-python or
site-packages directory.
...
A t
M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
The PEP provides a way to solve this use case by giving both developers
and users a standard at hand which they can fo
P.J. Eby wrote:
At 06:15 PM 4/15/2009 +0200, M.-A. Lemburg wrote:
The much more common use case is that of wanting to have a base package
installation which optional add-ons that live in the same logical
package namespace.
Please see the large number of Zope and PEAK distributions on PyPI as
P.J. Eby wrote:
It's unclear, however, who is using base packages besides mx.* and ll.*,
although I'd guess from the PyPI listings that perhaps Django is. (It
seems that "base" packages are more likely to use a 'base-extension'
naming pattern, vs. the 'namespace.project' pattern used by "pure"
Martin v. Löwis wrote:
In either of the proposals on the table, what code would I write and
where to have a base package with a set of add-on packages?
I don't quite understand the question. Why would you want to write code
(except for the code that actually is in the packages)?
PEP 382 is com
Where you just want "a damned valid email and stop making my life
hard!":
Message['Subject']='Some text'
Yes. In which case I propose we guess the encoding as 1) ascii, 2)
utf-8, 3) wtf?
Well, we're talking about Python 3 here right? In which case the above
involves only unicode, so why d
Stephen J. Turnbull wrote:
> > str(message['Subject'])
>
> Yes for unstructured headers like Subject. For structured headers...
> hmm.
Well, suppose we get really radical here. *People* see email as
(rich-)text. So ... message['Subject'] returns an object, partly to
be consistent with
P.J. Eby wrote:
I didn't say there's *no* desire, however IIRC the only person who
*ever* asked on distutils-sig how to do a base package with setuptools
was the author of the ll.* packages.
I've asked before ;-)
Chris
--
Simplistix - Content Management, Zope & Python Consulting
Martin v. Löwis wrote:
I, for one, have been trying to figure out how to do "base namespace"
packages for years...
You mean, without PEP 382?
That won't be possible, unless you can coordinate all addon packages.
Base packages are a feature solely of PEP 382.
Marc-Andre has achieved this, I t
Martin v. Löwis wrote:
Ok, so create three tar files:
1. base.tar, containing
simplistix/
simplistix/__init__.py
So this __init__.py can have code in it? And base.tar can have other
modules and subpackages in it?
What happens if the base and an addon both define a package called
simpl
Martin v. Löwis wrote:
So this __init__.py can have code in it?
That's the point, yes.
And base.tar can have other modules and subpackages in it?
Certainly, yes.
Great, when is the PEP due to land in 2.x? ;-)
What happens if the base and an addon both define a package called
simplistix.
Jeroen Ruigrok van der Werven wrote:
-On [20090509 13:40], "Martin v. Löwis" (mar...@v.loewis.de) wrote:
There are a few others, though: zope.*, repoze.*, redturtle.*, iw.*,
plone.*, pycopia.*, p4a.*, plonehrm.*, plonetheme.*, pbp.*, lovely.*,
xm.*, paste.*, Products.*, buildout.*, five.*, silva
Paul Moore wrote:
2009/5/9 Chris Withers :
Martin v. Löwis wrote:
I thought .pth files just had python in them?
Not at all - they never did. They have paths in them.
I've certainly seen them with python in, and that's what I hate about
them...
AIUI, there was a small special
Hi All,
I'd like to work on this issue:
http://bugs.python.org/issue2576
Specifically, in my case, while IE can download a 150Mb file from a
local server in about 3 seconds, httplib takes over 20 minutes!
However, I'm kinda stumped on where to start with debugging the
difference. I've tried
Antoine Pitrou wrote:
Chris Withers simplistix.co.uk> writes:
However, I'm kinda stumped on where to start with debugging the
difference. I've tried upping the buffer size as suggested in the issue,
but it's had no effect...
Then perhaps it's not the same bug.
Pl
Guido van Rossum wrote:
Try instrumenting the actual calls to the lowest-level socket methods
(recv() and send()) and log for each one the arguments, return time,
and how long it took.
Can I do that in python code?
You might see a pattern. Is this on Windows?
Well, yes, but I'm not 100%. Th
Hi All,
Is the Express Edition of Visual C++ 2008 suitable for compiling
packages for Python 2.6 on Windows?
(And Python 2.6 itself for that matter...)
Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?)
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python C
Michael Foord wrote:
D'oh. For 2.5 I mean. It may be *possible* though - just as you *can*
build extensions for Python 2.5 on windows with mingw (with the
appropriate distutils configuration), but there are pitfalls with doing
this.
Yes, in my case I'm trying to compile guppy (for heapy, whic
John Arbash Meinel wrote:
Guppy doesn't compile on Windows. Pretty much full-stop. It uses static
references to DLL functions, which on Windows is not allowed.
This is no longer true as of the latest version of guppy...
I've tried patching it to remove such things, and I finally got it to
com
Mail Delivery System wrote:
This is the mail system at host server1.simplistix.co.uk.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include th
Guido van Rossum wrote:
Anyway it looks like if someone wants to try this, only the code in
runpy.py needs to be touched.
Where is runpy.py to be found?
I'm trying to find whatever implements python -m and the other python
command line options...
Chris
--
Simplistix - Content Management, B
Benjamin Peterson wrote:
2009/8/24 Chris Withers :
Guido van Rossum wrote:
Anyway it looks like if someone wants to try this, only the code in
runpy.py needs to be touched.
Where is runpy.py to be found?
$ find . -name "runpy.py"
./Lib/runpy.py
Heh, grep beats Mk I eyeball
Hi All,
I'm being bitten by this issue:
http://bugs.python.org/issue1734860
I'm not sure I agree with Daniel's closing of it so thought I'd ask here...
Am I right in thinking that the general idea is that "the current
working directory at the time of invoking a script or interpreter ends
up
Hi All,
Would anyone object if I removed the deletion of of
sys.setdefaultencoding in site.py?
I'm guessing "yes!" so thought I'd state my reasons now:
This deletion appears to be pretty flimsy; reload(sys) and you have it
back. Which is lucky, because I need it after it's been deleted...
Nick Coghlan wrote:
The details of the sys.path manipulation at program startup are
documented here:
http://docs.python.org/using/cmdline.html#command-line
The directory prepended to sys.path is based on the code executed by the
command line.
It's more subtle than that though...
The OP in htt
exar...@twistedmatrix.com wrote:
The ability to change the default encoding is a misfeature. There's
essentially no way to write correct Python code in the presence of this
feature.
How so? If every single piece of text in your project is encoded in a
superset of ascii (such as utf-8), why w
M.-A. Lemburg wrote:
Let's look at this from another angle: sys.setdefaultencoding()
is only made available for use in site.py.
...see this:
http://mail.python.org/pipermail/python-dev/2009-August/091391.html
I would like to use sitecustomize.py for all the very good reasons given
in this t
Guido van Rossum wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Crazy idea: how about mutating it into sys._setdefaultencoding rather
than deleting it?
Chris
--
Simplistix - Content Management, Batc
Martin v. Löwis wrote:
In retrospect, it should have been called sys._setdefaultencoding().
That sends an extra signal that it's not meant for general use.
Crazy idea: how about mutating it into sys._setdefaultencoding rather
than deleting it?
Please don't post crazy ideas unless you really me
Martin v. Löwis wrote:
The ability to change the default encoding is a misfeature. There's
essentially no way to write correct Python code in the presence of
this feature.
How so? If every single piece of text in your project is encoded in a
superset of ascii (such as utf-8), why would this be
Martin v. Löwis wrote:
- If people were somehow relying on sys not having an attribute called
_setdefaultencoding, or were relying on stuffing an attribute into sys
called _setdefaultencoding then... well... that seems pretty unlikely ;-)
If people were using the reload trickery, that would bre
Nick Coghlan wrote:
The PEPs don't go into the process of how we actually hook the command
line up to the runpy module though - that's something you need to dig
into the main.c code to really understand.
Yeah, main.c does quite a lot... ;-)
This all spawned from a suggestion by Jim Fulton over
Nick Coghlan wrote:
Ah, OK - I see the problem now. However, I think the current behaviour
is correct, it just needs to be documented better (probably noted in
both the command line doco
Not sure what you mean by this?
regarding sys.path manipulation and in the
doco for site.py).
Agreed :-
Guido van Rossum wrote:
Being adults about it also means when to give up. Chris, please stop
arguing about this.
Sure. Even if people had agreed to this change, it wouldn't end up in a
python release I could use for this project.
There are plenty of techniques you can use to get
what you w
Robert Brewer wrote:
you could switch to Python 3.1,
I would love to, once Python 3 has a viable web app story...
CherryPy 3.2 is now in beta, and mod_wsgi is nearly ready as well. Both
support Python 3. :)
My understanding was that the wsgi spec for Python 3 wasn't finished...
Chris
--
Si
Guido van Rossum wrote:
You might see a pattern. Is this on Windows?
Well, yes, but I'm not 100%. The problematic machine is a Windows box, but
there are no non-windows boxes on that network and vpn'ing from one of my
non-windows boxes slows things down enough that I'm not confident what I'd
be
Simon Cross wrote:
Well, since the source for _read_chunked includes the comment
# XXX This accumulates chunks by repeated string concatenation,
# which is not efficient as the number or size of chunks gets big.
you might gain some speed improvement with minimal effort by gather
Antoine Pitrou wrote:
Simon Cross gmail.com> writes:
Well, since the source for _read_chunked includes the comment
# XXX This accumulates chunks by repeated string concatenation,
# which is not efficient as the number or size of chunks gets big.
you might gain some speed impro
Hi All,
Anyone know what's causing this failure?
test test___all__ failed -- Traceback (most recent call last):
File "Lib/test/test___all__.py", line 106, in test_all
self.check_all("profile")
File "Lib/test/test___all__.py", line 23, in check_all
exec("from %s import *" % modname, n
Guido van Rossum wrote:
+1 on trying this. Constructing a 116MB string by concatenating 1KB
buffers surely must take forever. (116MB divided by 85125 recv() calls
give 1365 byte per chunk, which is awful.) The HTTP/1.0 business looks
like a red herring.
Also agreed that this is an embarrassment.
David Lyon wrote:
On Tue, 08 Sep 2009 09:18:50 +0100, Chris Withers
wrote:
If Python had a packaging system *and* used it for the standard library,
then things like this wouldn't be a problem...
The setup.cfg could just say "requires sqlite greater than version
x.y.z", and i
Tarek Ziadé wrote:
The four sentences summary for people in a hurry:
If you're going to promise sentences, please deliver sentences...
Getting metadata of a distribution that is not.
installed means running its setup.py. This means.
downloading the whole archive, and running.
Hi All,
I didn't see any docs on this:
http://docs.python.org/reference/datamodel.html?highlight=__eq__#object.__eq__
Where are the specifications on what happens if two objects are compared
and both have implementations of __eq__? Which __eq__ is called? What
happens if the first one called
Jared Flatow wrote:
This might help:
http://mail.python.org/pipermail/python-dev/2008-June/080111.html
Here is the most relevant part (quoting Guido):
> Does it help if I tell you that for "x y" we always try
> x.__binop__(y) before trying y.__reverse_binop__(x), *except* in the
> case whe
Tarek Ziadé wrote:
Yes, for the syntax bikeshedding on how conditions should be expressed,
I have decided I'll be some kind of distutils dictator to end up the
endless discussions
on how they should be expressed so we can move on.
...except in this case, spelling is important and I'm far from t
Brett Cannon wrote:
OK, stop before it gets any nastier as your email already sounds rude, Chris.
Yes, apologies.
Since the language summit at PyCon 2009 various committers, including
me, have been encouraging Tarek to act as distutils dictator to get
things finished as we all know people are
Mark Dickinson wrote:
I (still :-) think this is covered, for Python 2.x at least, by:
http://docs.python.org/reference/datamodel.html#coercion-rules
But this isn't coercion! :-)
- For objects x and y, first x.__op__(y) is tried. If this is not
implemented or returns NotImplemented, y.__rop_
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/
Frank Wierzbicki wrote:
Talk has started up again on the stdlib-sig list about finding a core
stdlib + tests that can be shared by all implementations, potentially
living apart from CPython. I have volunteered to put together a PEP
on the subject, with Jessie Noller and Brett Canon are helping m
Antoine Pitrou wrote:
This sounds like a bad idea to me. Each Python release is tested and debugged as
a whole. If you have a lot of possible combinations (module A version 1.1 with
module B version 1.2, etc.), it becomes impossible for us to ensure proper QA
for the whole and as a result the qua
P.J. Eby wrote:
Here's what actually happened, if anyone cares. Tarek and friends
announced a fork of setuptools. I reviewed the work and saw that -- for
the most part -- I was happy with it, and opined as how I might be
willing to bless the the "package inquisition" team as official
maintai
Antoine Pitrou wrote:
As far as I'm concerned, anything which looks intuitive enough (e.g. ini-style)
and not overly complicated is fine. The details of the syntax aren't really
important as long as they make sense, and don't get in the way.
This is a variant of "as simple as possible and requi
Nick Coghlan wrote:
Really? I can understand package owners not being able to add
recommendations for their own packages, but if they can't add comments
how are they meant to correct misunderstandings or redirect
inappropriate messages to the correct forums?
Indeed, yet another reason I would l
M.-A. Lemburg wrote:
We've implemented our own bdist_egg now which doesn't use setuptools
and will start to ship eggs in addition to our prebuilt format with
the next releases.
Egg-cellent ;-)
Any chance this tool is open source? Better yet, could it make its way
into distutils asap?
Chris
Fredrik Lundh wrote:
Oh, it was just yet another Zope developer behaving like an ass. Why
am I not surprised?
Actually Plohn, there aren't that many Zope developers left ;-)
Chris - looking mournfully at his sig...
--
Simplistix - Content Management, Batch Processing & Python Consulting
Fredrik Lundh wrote:
Looks like the quickest fix is to distribute two source packages, one
built the traditional way to eliminate breakage for people using the
current tarball layout, and one built with "sdist".
Why the need for two?
Or, asked differently, who would be hurt if the distribution
Tarek Ziadé wrote:
Notice that I am also doing nightly builds of Distutils that can be installed
and tried in released version of Python, and that can be used instead of the
Python's embed Distutils (see the installable tarballs at nightly.ziade.org).
so maybe it's just a matter of continuous in
Barry Warsaw wrote:
2) PJE releases a new version of setuptools that fixes this problem.
3) We (a.k.a. Tarek with our blessing) hijacks the setuptools name (e.g.
on cheeseshop) and releases a new version
It's a shame you didn't suggest this sooner. It would have avoided the
need for the sepe
M.-A. Lemburg wrote:
mxSetup.py, the module implementing all our distutils extensions,
is available in egenix-mx-base which is open source:
http://www.egenix.com/products/python/mxBase/
I have memories of mxBase having a load of other stuff in it too?
Would it be possible to split jus
Hi Phil,
It's almost a week since I made this offer. I haven't heard anything
from you. If I've missed anything please let me know and I'll track it
down, otherwise I hope you can have a look at this some time soon.
cheers,
Chris
Chris Withers wrote:
P.J. Eby wrote:
M.-A. Lemburg wrote:
Would it be possible to split just the distutils extensions into their
own package and get that package as an sdist on PyPI?
Nope.
shame :-(
The complicated stuff does belong somewhere else, but the
basic things need to go into the filename
But everyone's basic thin
Guido van Rossum wrote:
I'm saying that I don't expect setuptools 0.7 to appear before Tarek's
Distribute is mature and in widespread use. IOW I support Tarek's fork
and suggest nobody hold their breath waiting for setuptools 0.7.
Well, if this was the BDFL pronouncement that a lot of people ha
Tarek Ziadé wrote:
== The fate of setup.py, and static metadata ==
So we are going to separate the metadata description from setup.py, in
a static configuration file, that can be open and read by anyone
without
running any code.
So we've worked on that lately in Distutils-SIG and came up wi
Tarek Ziadé wrote:
Some new commands are added there, when they are helpful and don't
interact with the rest. I am thinking
about "upload_docs" that let you upload documentation to PyPI. The
goal is to move it to Distutils
at some point, if the documentation feature of PyPI stays and starts to be
Tarek Ziadé wrote:
- The code is splitted in many packages and might be distributed under
several distributions.
- distribute.resources: that's the old pkg_resources, but
reorganized in clean, pep-8 modules. This package will
only contain the query APIs and will focus on being PEP 376
co
Tarek Ziadé wrote:
= Virtualenv and the multiple version support in Distribute =
(I am not saying "We" here because this part was not discussed yet
with everyone)
Good, so maybe take this discussion to distutils-sig first?
Virtualenv allows you to create an isolated environment to install
so
Tarek Ziadé wrote:
How about helping the author of that extension make it work with Distribute
or just get that implementation into Distutils core instead?
It's the case. The author is a Distribute commiter and *he* has added
it in Distribute.
Great, but about just getting it into Distutils?
Tarek Ziadé wrote:
- distribute.entrypoints: that's the old pkg_resources entry points
system, but on its own. it uses distribute.resources
Why not get it into the core as distutils.entrypoints? That's where it
belongs...
What do you call 'core' ? distutils.core ?
Sorry, mean stdlib. distu
Tarek Ziadé wrote:
This PyPI feature is pretty new. It's great to have the client command
on Distribute.
If its usage spreads it'll make it to Distutils.
If you want to see it included Distutils (I do too) help us promoting its usage
The only thing that discourages me from using the PyPI docs
Tarek Ziadé wrote:
NB: There was no consensus on this "micro-language" on distutils-sig.
While I suspect I don't care as none of my packages rely on anything other
than other python packages, others did care, and I found the syntax Tarek
was proposing pretty clumsy.
Please no bikeshedding again
Tarek Ziadé wrote:
At Python and PyPI level, 'Setuptools' is PJE's project and he's the
one that manages the list of users that have
extended rights on his project.
Indeed, if only he would see sense :-(
In Distribute, our setup.py script makes sure setuptools is not in the
way. It is explici
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:51:00PM +0100, Chris Withers wrote:
Tarek Ziadé wrote:
Virtualenv allows you to create an isolated environment to install
some distribution without polluting the
main site-packages, a bit like a user site-packages.
...as does buildout, and
[following up on distutils-sig]
Michael Foord wrote:
Many Windows users would be quite happy if the standard mechanism for
installing non-source distributions on Windows was via the wininst
binaries.
...and many users may not be ;-) I know I'd be extremely unhappy if that
were the case as I
Chris Withers wrote:
[following up on distutils-sig]
...FAIL, sorry for the noise.
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
___
Python-Dev mailing list
Python
Martin v. Löwis wrote:
I'm going to take a poll RSN, and see what the majority of users
think (rather than their vocal fraction). Then we can see what to do
about it.
Yes please! I've been silently waiting for this and have (surprisingly
for me!) managed to resist joining in the rant.
I'm of
Arc Riley wrote:
It would be more useful to provide a PyPI mechanism to publish a link to
file bugs on the project's own website and leave project ratings the
work of other sites such as Ohloh.
Yes, I really wish I could include all the links in the sections on,
say, http://www.simplistix.co.
Jacob Kaplan-Moss wrote:
that obscures the real debate. Regardless of the outcome, the poll's
not going to change anyone's mind, and it certainly won't change the
fact that PyPI's being run as a one-man show, not as a community
resource.
While I may not agree on his choices regarding comments a
Steven D'Aprano wrote:
That's three choices for allowing comments, two for disallowing.
Sorry, I should have been more explicit:
The first choice makes comments compulsory. In other words, comments are
allowed.
The second choice makes comments optional. Whether it is opt-in or
opt-out, PyP
Tarek Ziadé wrote:
On behalf of the Distutils-SIG, I would like to propose PEP 386 for
inclusion in the sdtlib, and have a final discussion here on
Python-dev.
http://www.python.org/dev/peps/pep-0386
This is excellent. Thankyou for doing this, I hope we can get it
accepted and implemented as
Hi All,
Is there a high volume of incoming bugs to the Python tracker?
If so, I'd like to help with triaging. I think I have all the necessary
access, what I'm missing is the knowledge of how to set myself up to get
notifications of new bugs...
How do I do that?
cheers,
Chris
--
Simplistix
Michael Foord wrote:
I assumed there would be RSS feeds for bug tracker activity but can't
easily find these on the tracker. There is a bot that posts activity to
#python-dev, so there must be some way of getting this information.
Yeah, email-out is what I'm really after... I have it for my ow
Nick Coghlan wrote:
I'm pretty sure the bugs list is still the primary spooled notification
mechanism:
http://mail.python.org/mailman/listinfo/python-bugs-list
That's what I was after, thanks!
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://w
Tarek Ziadé wrote:
Another useful triage I think, is to review the oldest bugs (some of
them are > 5 years)
and remove the ones that are not relevant anymore, or duplicate with
newer entries.
I'm sprinting for 2 days at PyCon, I'd verymuch be up for doing this
with someone as a paired task for
R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with get_class_cm(test_instance): # How
Hi All,
The documentation for the logging package doesn't include any mention of
unicode.
What's the recommended usage in terms of passing unicode vs encoded strings?
How does this differ from Python 2 to Python 3?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python
Hi All,
http://www.python.org/download/releases/2.6.6/
..includes the text:
"This is a release candidate; we currently support these formats:"
Is that text meant to be there?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simpl
Hi All,
Following on from this question:
http://twistedmatrix.com/pipermail/twisted-python/2010-September/022877.html
...I'd thought that the "correct names" for distributions would have
been documented in one of:
http://www.python.org/dev/peps/pep-0345
http://www.python.org/dev/peps/pep-037
Hi All,
I'm curious as to why, with a file called "Foo.txt" on a case
descriminating but case insensitive filesystem,
os.path.normcase('FoO.txt') will return "foo.txt" rather than "Foo.txt"?
Yes, I know the behaviour is documented, but I'm wondering if anyone can
remember the rationale for t
On 17/09/2010 12:54, Dan Buch wrote:
You may also find this thread from the packaging google group useful,
although it may not be quite what you're looking for:
http://bit.ly/96SMuM
To echo a please from the main python list, please can we all stop using
url shortening services?
This i
On 18/09/2010 23:36, Guido van Rossum wrote:
course, exists() and isdir() etc. do, and so does realpath(), but the
pure parsing functions don't.
Yes, but:
H:\>echo foo > TeSt.txt
...>>> import os.path
>>> os.path.realpath('test.txt')
'H:\\test.txt'
>>> os.path.normcase('TeSt.txt')
'test.txt'
On 22/09/2010 16:54, Vinay Sajip wrote:
I'm planning to make some smallish changes to logging in Python 3.2, please see
http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html
If you're interested, I'd be grateful for any feedback you can give.
Cool, how can I use it
On 24/09/2010 12:06, Vinay Sajip wrote:
http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html
Cool, how can I use it in Python 2.6? :-)
1. Copy the top part (imports, QueueHandler and QueueListener classes) from the
Gist linked to in the article - http://gist.gith
On 25/09/2010 04:25, Steven D'Aprano wrote:
1. Return the case of a filename in some canonical form which depends
on the file system?
2. Return the case of a filename as it is actually stored on disk?
How do 1 and 2 differ? FWIW, the use case that setuptools has (and for
which it currently
On 25/09/2010 15:45, Guido van Rossum wrote:
The solution may well be OS specific. Solutions for Windows and OS X
have already been pointed out. If it can't be done for other Unix
versions, I think returning the input unchanged on those platform is a
fine fallback (as it is for non-existent filen
On 05/10/2010 12:04, Steven D'Aprano wrote:
On Tue, 5 Oct 2010 07:21:15 pm Chris Withers wrote:
On 25/09/2010 04:25, Steven D'Aprano wrote:
1. Return the case of a filename in some canonical form which
depends on the file system?
2. Return the case of a filename as it is actually
On 05/10/2010 13:00, Antoine Pitrou wrote:
3. stay with versioned project file names and rename 'python-wing.wpr'
to 'python-wing3.wpr'
(Option 3 could be done immediately of course.)
Option 3 looks the most reasonable to me.
I don't use Wing, but option 3 does seem most sensible.
Explicit-
101 - 200 of 250 matches
Mail list logo
